While we're already having a working code base for a dedicated Bluetooth host dongle function driver supporting genuine and fake DS3s I wanna also explore the path of a different approach: keeping the default Windows Bluetooth driver stack in place and patching it in a way that it will accept a DS3 connection transparently in parallel to other devices (keyboards, headsets etc.) via filter driver.

Analysis environment

• Windows 7 32-Bit
• Generic Bluetooth Radio (Cambridge Silicon Radio Ltd.)
  • Hardware ID: USB\VID_0A12&PID_0001
• Genuine Sony DualShock 3 controller

Tools used

• DebugView
• RequestTrace

Analysis

On Interrupt Pipe (HCI communication) connection seems to work at least until receiving HCI_Remote_Name_Request_Complete_EV:

This corresponds to this

in AirBender/WireShock. The HCI_Command_Remote_Name_Request is the last HCI command which has to succeed, which looks like it does. Next is building the L2CAP connection, which seems to get initiated as well a few requests later:

As buffer[6] == 0x01 && buffer[7] == 0x00 represents the L2CAP control channel. So the L2CAP ping-pong should be looked at in greater detail and find the stage where it starts to break.

L2CAP_Connection_Request

00000181	0.82300282	** RT_CompletionRoutineUrbSubmit: Irp: 0x854DC8B8 - IOCTL_INTERNAL_USB_SUBMIT_URB - URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER - Status STATUS_SUCCESS - Buffer: 0x85703000, MDL: 0x887905F0, Length: 0x10, Pipe:0x85A2137C, Flags: 0x3.	
00000182	0.82301444	** 42 20 0C 00 08 00 01 00  02 01 04 00 11 00 40 7C  B ............@|	
00000183	0.82302463	** 42 20 0C 00 08 00 01 00  02 01 04 00 11 00 40 7C  B ............@|	
00000184	0.82304817	** Irp: 0x854DC8B8 - IOCTL_INTERNAL_USB_SUBMIT_URB - URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER. Buffer: 0x878B3000, MDL: 0x0, Length: 0x1000, Pipe:0x85A2137C, Flags: 0x3.	

This gets repeated over and over again, so either the correct answer is missing in the trace or not sent at all.

This .INF section will add driver as a lower class filter driver for the Bluetooth class (GUID: {e0cbf06c-cd8b-4647-bb8a-263b43f0f974}) and load it on every BTHUSB host device:

[Filter_Device.NT.HW]
AddReg = Filter_AddReg

[Filter_AddReg]
HKLM,SYSTEM\CurrentControlSet\Control\Class\{e0cbf06c-cd8b-4647-bb8a-263b43f0f974},LowerFilters,0x00010008,Filter

Section for uninstallation missing.

EDIT: obsolete, will do this via helper tool instead of INF file.

Gotcha!

2018/12/30-22:27:05.535	TRACE_LEVEL_VERBOSE	>> IOCTL_INTERNAL_USB_SUBMIT_URB
2018/12/30-22:27:05.535	TRACE_LEVEL_VERBOSE	>> >> URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (PipeHandle: 854C164C)
2018/12/30-22:27:05.535	TRACE_LEVEL_VERBOSE	Bulk OUT transfer
2018/12/30-22:27:05.535	TRACE_LEVEL_INFORMATION	3C 00 10 00 0C 00 01 00 03 01 08 00 00 00 40 21 02 00 00 00 
2018/12/30-22:27:05.535	TRACE_LEVEL_INFORMATION	L2CAP_Connection_Response (Response: 02)

Byte 8 is L2CAP_Connection_Response from Windows Bluetooth driver, byte 16 is status:

/// <summary>
///     Connection refused – PSM not supported.
/// </summary>
L2CAP_ConnectionResponseResult_ConnectionRefusedPsmNotNupported = 0x0002

This is kinda nice to know because it's the very first L2CAP connection failing because the PSM (Protocol/Service Multiplexer) the DS3 wants to establish a channel for is forbidden in Windows. Let's patch that and see what happens

Why this happens is actually documented, especially:

Some PSMs are reserved for use by Windows:
SDP: 0x01
RFCOMM: 0x03
HID Control: 0x11
HID Data: 0x13
BNEP: 0x0F

It is well-known that the DS3 establishes communication channels via PSM 0x11 and 0x13, which works fine on the PS3 (custom Bluetooth stack firmware) and Linux (no such reservations/limitations). On Windows however this is a pretty big deal and the showstopper for an out-of-the-box working connection of a DS3 with standard Windows Bluetooth stack.

A pretty neat hack around this limitation was discovered a few years back, but API hooking or binary patches in kernel space are strictly forbidden (mainly for stability and security reasons, even Anti-Virus vendors had to back down from this approach starting with the Vista kernel) so while having this info as a fallback, it's not something we can use in production and therefore a KMDF Bluetooth Profile Driver won't be helpful here.

Will further go down and explore the lower BTHUSB filter route

Hm, even if nothing of this works in the end: I've now accidentally created a Bluetooth sniffer which is nice

I abandoned the Bluetooth Profile Driver idea to soon; let's see what this skeleton can do for me

Oh my! This actually worked

I've currently set up a BTHUSB lower filter driver simply looking for an incoming L2CAP connection request with the dredded PSM 0x11 and patching it to an artificial fixed value (currently 0x5053)

UrbFunctionBulkInTransferCompleted	2019/01/01-15:26:42.733	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/01-15:26:42.733	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
UrbFunctionBulkInTransferCompleted	2019/01/01-15:26:42.733	TRACE_LEVEL_INFORMATION	++ PSM: 0x11
UrbFunctionBulkInTransferCompleted	2019/01/01-15:26:42.733	TRACE_LEVEL_INFORMATION	++ Patching PSM to 0x5053

This grants us a way around bthport.sys!BthIsSystemPSM denying the connection right away, so far so good! But that's not enough; how should the Bluetooth stack now know what to do with a non-existent PSM? Well, we need to register a custom Profile Driver for it, of course!

2019/01/01-15:26:31.001	TRACE_LEVEL_INFORMATION	++ Trying to register PSM 0x5053
2019/01/01-15:26:31.001	TRACE_LEVEL_INFORMATION	++ Got PSM 0x5053
2019/01/01-15:26:31.001	TRACE_LEVEL_VERBOSE	BthPS3RegisterPSM Exit
2019/01/01-15:26:31.001	TRACE_LEVEL_VERBOSE	BthPS3RegisterL2CAPServer Entry
2019/01/01-15:26:31.001	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/01-15:26:31.001	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/01-15:26:31.001	TRACE_LEVEL_VERBOSE	BthPS3RegisterL2CAPServer Exit
2019/01/01-15:26:42.763	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/01-15:26:42.763	TRACE_LEVEL_INFORMATION	BthPS3IndicationCallback ++ IndicationRemoteConnect
2019/01/01-15:26:42.763	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit

And we actually receive the connection request in our own profile driver now

That is... very interesting! Let's see where the road leads me from here on.

PSMs shall be odd and the least significant bit of the most significant byte shall be zero, hence the following ranges do not contain valid PSMs: 0x0100-0x01FF, 0x0300-0x03FF, 0x0500-0x05FF, 0x0700-0x07FF, 0x0900-0x09FF, 0x0B00-0x0BFF, 0x0D00-0x0DFF, 0x0F00-0x0FFF. All even values are also not valid as PSMs.

Really interesting, keep up the good work!

Am I right in assuming these are research notes for an Airbender successor?

@414n not quite, this is already a successor successor

The AirBender successor is code-named WireShock and already exists in the lab, has working support for fake DS3s and doesn't require additional software to function (AirBender needs Shibari to actually function).

However, WireShock is - like AirBender - a USB function driver, which means it needs to replace the entire default Windows Bluetooth driver which means your Bluetooth host gets unusable for anything else that is not a DualShock. That's the same technique ScpToolkit used.

This research is my attempt to discover "the holy grail"; a solution which keeps the existing Bluetooth drivers in place so headsets, keyboards etc. keep working but allows transparent co-existence with DualShock/Nav/Move 3 devices.

Right, now that we've gotten so far to send back a connection response, the second channel pops up and requires a "proxy-PSM" as well:

UrbFunctionBulkInTransferCompleted	2019/01/05-18:11:16.983	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
UrbFunctionBulkInTransferCompleted	2019/01/05-18:11:16.983	TRACE_LEVEL_INFORMATION	++ PSM: 0x13

May I just add that writing a Bluetooth Profile Driver takes forever even if you can steal big chunks of code from the Windows driver samples

Oh yeah, registering a proxy PSM for PSM_HID_INTERRUPT as well shoots us even further forward:

UrbFunctionInterruptInTransferCompleted	2019/01/05-21:13:01.717	TRACE_LEVEL_INFORMATION	HCI_Connection_Complete_EV
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.742	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.742	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.742	TRACE_LEVEL_INFORMATION	++ PSM: 0x11
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.742	TRACE_LEVEL_INFORMATION	++ Patching PSM to 0x5053
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.763	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.763	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.765	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.765	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.771	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.771	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.771	TRACE_LEVEL_INFORMATION	++ PSM: 0x13
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.771	TRACE_LEVEL_INFORMATION	++ Patching PSM to 0x5055
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.781	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.781	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.783	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
UrbFunctionBulkInTransferCompleted	2019/01/05-21:13:01.783	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response

Which generates some more noise in the profile driver:

2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/05-21:13:01.379	TRACE_LEVEL_INFORMATION	BthPS3IndicationCallback ++ IndicationRemoteConnect
2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3SendConnectResponse Entry
2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/05-21:13:01.379	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/05-21:13:01.389	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Entry
2019/01/05-21:13:01.389	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/01/05-21:13:01.389	TRACE_LEVEL_INFORMATION	Connection established with client
2019/01/05-21:13:01.389	TRACE_LEVEL_INFORMATION	Connection completed, connection: 0xFFFFFA80089CC0C0
2019/01/05-21:13:01.389	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Exit
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/05-21:13:01.395	TRACE_LEVEL_INFORMATION	BthPS3IndicationCallback ++ IndicationRemoteConnect
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3SendConnectResponse Entry
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/05-21:13:01.395	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/05-21:13:01.413	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Entry
2019/01/05-21:13:01.413	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_DEVICE_NOT_CONNECTED (0xC000009D)
2019/01/05-21:13:01.413	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Exit

Now ofc. the state machine I ripped off the bthecho sample driver goes crazy here and the connection drops but both channels connection requests actually bubble up to our driver, that's good news

Btw. if you attempt to register one of the "forbidden" PSMs within your profile driver like so:

DevCtx->Header.ProfileDrvInterface.BthReuseBrb(
        &(DevCtx->RegisterUnregisterBrb),
        BRB_REGISTER_PSM
    );

brb = (struct _BRB_PSM *)
	&(DevCtx->RegisterUnregisterBrb);

brb->Psm = PSM_HID_CONTROL; // LOL, nope

status = BthPS3SendBrbSynchronously(
	DevCtx->Header.IoTarget,
	DevCtx->Header.Request,
	(PBRB)brb,
	sizeof(*brb)
);

the system crashes no NT_STATUS failure code, you'll be sent straight to hell. So, uh, don't do that

This is how the profile driver could look like, notice the original host driver still being in place:

The Hardware ID would be BTHENUM\{CUSTOM_SERVICE_GUID} where in my lab example I simply recycled the one bthecho uses:

The service GUID I registered with a WinAPI call to BluetoothSetLocalServiceInfo:

DWORD SetBthServiceInfo(
    BOOLEAN bEnabled
    )
{
    DWORD err = ERROR_SUCCESS;
    BLUETOOTH_LOCAL_SERVICE_INFO SvcInfo = {0};
    SvcInfo.Enabled = bEnabled;

    if (FAILED(StringCbCopyW(SvcInfo.szName, sizeof(SvcInfo.szName), BthEchoSampleSvcName)))
    {
        printf("Copying svc name failed\n");
        goto exit;
    }

    if (ERROR_SUCCESS != (err = BluetoothSetLocalServiceInfo(
        NULL, //callee would select the first found radio
        &BTHECHOSAMPLE_SVC_GUID,
        0,
        &SvcInfo
        )))
    {
        printf("BluetoothSetLocalServiceInfo failed, err = %d\n", err);
        goto exit;        
    }
exit:
    return err;    
}

Again, simply taken from the Microsoft sample. I also noticed, that the bthsrvinst project links against BluetoothApis.lib, which bombs on Windows 7. Link against Bthprops.lib instead and it will work.

Supported in Windows 8 and later versions of Windows.

2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/08-18:50:55.893	TRACE_LEVEL_INFORMATION	New connection for 5053 from AC7A4D2819AC arrived
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponsePendingCompleted Entry
2019/01/08-18:50:55.893	TRACE_LEVEL_INFORMATION	Connection PENDING completed with status: STATUS_SUCCESS (0x00000000)
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponsePendingCompleted Exit
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/08-18:50:55.893	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/08-18:50:55.904	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Entry
2019/01/08-18:50:55.904	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/01/08-18:50:55.904	TRACE_LEVEL_INFORMATION	Connection established with client
2019/01/08-18:50:55.904	TRACE_LEVEL_INFORMATION	Connection completed, connection: 0xFFFFFA8009F6C480
2019/01/08-18:50:55.904	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Exit
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/08-18:50:55.911	TRACE_LEVEL_INFORMATION	New connection for 5055 from AC7A4D2819AC arrived
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponsePendingCompleted Entry
2019/01/08-18:50:55.911	TRACE_LEVEL_INFORMATION	Connection PENDING completed with status: STATUS_SUCCESS (0x00000000)
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponsePendingCompleted Exit
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/08-18:50:55.911	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/08-18:50:55.927	TRACE_LEVEL_VERBOSE	BthPS3RemoteConnectResponseCompletion Entry

Right, so the connection handshake works for both Control and Interrupt channel, now I need to copypasta a ton of code to send and respond to the configuration requests. And extend the state machine to handle two channels instead of one like the example code intended. Oh dear

Nope, wrong assumption. The profile driver doesn't craft configuration requests, the parent driver does.

Sniff-log from under BTHUSB:

2019/01/08-19:06:14.202	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
2019/01/08-19:06:14.233	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 01)
2019/01/08-19:06:14.233	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 01)
2019/01/08-19:06:14.233	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 00)
2019/01/08-19:06:14.233	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Request
2019/01/08-19:06:14.245	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request
2019/01/08-19:06:14.245	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Response
2019/01/08-19:06:14.247	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response
2019/01/08-19:06:14.253	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request
2019/01/08-19:06:14.253	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 01)
2019/01/08-19:06:14.253	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 01)
2019/01/08-19:06:14.253	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response (Response: 00)
2019/01/08-19:06:14.253	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Request
2019/01/08-19:06:14.266	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request
2019/01/08-19:06:14.266	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Response
2019/01/08-19:06:14.267	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response
2019/01/08-19:06:14.275	TRACE_LEVEL_INFORMATION	>> L2CAP_Disconnection_Request
2019/01/08-19:06:14.281	TRACE_LEVEL_INFORMATION	>> L2CAP_Disconnection_Request

That's both cool and frightening; hopefully the host knows what it's doing

Also, why is PENDING sent twice per channel did I do that or the host...

EDIT: I did that, no need for it, the parent driver has everything under control

Sniffing intensifies

2019/01/08-20:04:06.318	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x01, Length: 4, PSM: 0x5053, SCID: 0x1440]
2019/01/08-20:04:06.349	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0000, SCID: 0x1440, Result: 0x0001, Status: 0x0000]
2019/01/08-20:04:06.349	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0000, SCID: 0x1440, Result: 0x0001, Status: 0x0000]
2019/01/08-20:04:06.349	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0040, SCID: 0x1440, Result: 0x0000, Status: 0x0000]
2019/01/08-20:04:06.349	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x01, Length: 8, DCID: 0x1440, Flags: 0x0000, Options: 0x02A00201]
2019/01/08-20:04:06.360	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 4, DCID: 0x0040, Flags: 0x0000, Options: 0x00001000]
2019/01/08-20:04:06.361	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x1440, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/08-20:04:06.362	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x01, Length: 6, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0052]
2019/01/08-20:04:06.369	TRACE_LEVEL_INFORMATION	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x03, Length: 4, PSM: 0x5055, SCID: 0x1481]
2019/01/08-20:04:06.369	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0000, SCID: 0x1481, Result: 0x0001, Status: 0x0000]
2019/01/08-20:04:06.369	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0000, SCID: 0x1481, Result: 0x0001, Status: 0x0000]
2019/01/08-20:04:06.369	TRACE_LEVEL_INFORMATION	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0041, SCID: 0x1481, Result: 0x0000, Status: 0x0000]
2019/01/08-20:04:06.369	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 8, DCID: 0x1481, Flags: 0x0000, Options: 0x02A00201]
2019/01/08-20:04:06.380	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x04, Length: 28, DCID: 0x0041, Flags: 0x0000, Options: 0x02001603]
2019/01/08-20:04:06.381	TRACE_LEVEL_INFORMATION	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x04, Length: 30, SCID: 0x1481, Flags: 0x0000, Result: 0x0001, Options: 0x1603]
2019/01/08-20:04:06.383	TRACE_LEVEL_INFORMATION	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0052]
2019/01/08-20:04:06.389	TRACE_LEVEL_INFORMATION	>> L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x05, Length: 4, DCID: 0x0041, SCID: 0x1481]
2019/01/08-20:04:06.389	TRACE_LEVEL_INFORMATION	<< L2CAP_Disconnection_Response [Code: 0x07, Identifier: 0x05, Length: 4, DCID: 0x0041, SCID: 0x1481]
2019/01/08-20:04:06.399	TRACE_LEVEL_INFORMATION	>> L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x06, Length: 4, DCID: 0x0040, SCID: 0x1440]
2019/01/08-20:04:06.399	TRACE_LEVEL_INFORMATION	<< L2CAP_Disconnection_Response [Code: 0x07, Identifier: 0x06, Length: 4, DCID: 0x0040, SCID: 0x1440]

L2CAP Channel Configuration

MTU

A successful agreement on MTU value L2CAP_MAX_MTU:

<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x15, Length: 8, DCID: 0x3240, Flags: 0x0000, Options: 0xFFFF0201]
>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 4, DCID: 0x0040, Flags: 0x0000, Options: 0x02010000]
<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x3240, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x15, Length: 10, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x16, Length: 8, DCID: 0x3281, Flags: 0x0000, Options: 0xFFFF0201]
>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x16, Length: 10, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0201]

QOS

Controller and host currently can't agree on QUALITY OF SERVICE (QOS) OPTION.

Option 0x02001603 is translated to: 0x03 (QoS option type) with length of 22 (0x16) and requested option is 0x0200 (0x02 = Service Type as Guaranteed, L2CAP_FLOW_SERVICE_TYPE_GUARANTEED)

>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x04, Length: 28, DCID: 0x0041, Flags: 0x0000, Options: 0x02001603]
<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x04, Length: 30, SCID: 0x3281, Flags: 0x0000, Result: 0x0001, Options: 0x1603]

Ladies and gentlemen, we got him

The DS3 is connected to standard Windows Bluetooth Stack

I must be dreaming it actually works, my DS3 is connected to an USB Bluetooth dongle running the standard Windows Bluetooth Stack, the filter and the profile driver! git commit && git push

Lower filter log

2019/01/08-21:02:33.479	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x01, Length: 4, PSM: 0x5053, SCID: 0x42C0]
2019/01/08-21:02:33.491	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0000, SCID: 0x42C0, Result: 0x0001, Status: 0x0000]
2019/01/08-21:02:33.491	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0040, SCID: 0x42C0, Result: 0x0000, Status: 0x0000]
2019/01/08-21:02:33.491	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x03, Length: 8, DCID: 0x42C0, Flags: 0x0000, Options: 0xFFFF0201]
2019/01/08-21:02:33.497	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 4, DCID: 0x0040, Flags: 0x0000, Options: 0x00010004]
2019/01/08-21:02:33.497	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x42C0, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/08-21:02:33.499	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x03, Length: 10, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
2019/01/08-21:02:33.507	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x03, Length: 4, PSM: 0x5055, SCID: 0x4301]
2019/01/08-21:02:33.507	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0000, SCID: 0x4301, Result: 0x0001, Status: 0x0000]
2019/01/08-21:02:33.507	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0041, SCID: 0x4301, Result: 0x0000, Status: 0x0000]
2019/01/08-21:02:33.507	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x04, Length: 8, DCID: 0x4301, Flags: 0x0000, Options: 0xFFFF0201]
2019/01/08-21:02:33.516	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x04, Length: 28, DCID: 0x0041, Flags: 0x0000, Options: 0x02001603]
2019/01/08-21:02:33.516	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x04, Length: 6, SCID: 0x4301, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/08-21:02:33.519	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x04, Length: 10, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0201]

Profile driver log

2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/08-21:02:33.201	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/08-21:02:33.201	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/08-21:02:33.209	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponseCompleted Entry
2019/01/08-21:02:33.209	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/01/08-21:02:33.209	TRACE_LEVEL_INFORMATION	Connection established with client
2019/01/08-21:02:33.209	TRACE_LEVEL_INFORMATION	Connection completed, connection: 0xFFFFFA8009A7A5E0
2019/01/08-21:02:33.209	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponseCompleted Exit
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/08-21:02:33.216	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from AC7A4D2819AC arrived
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/08-21:02:33.216	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/08-21:02:33.225	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Entry
2019/01/08-21:02:33.225	TRACE_LEVEL_INFORMATION	BthPS3ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
2019/01/08-21:02:33.225	TRACE_LEVEL_VERBOSE	BthPS3ConnectionIndicationCallback Exit
2019/01/08-21:02:33.228	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponseCompleted Entry
2019/01/08-21:02:33.228	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/01/08-21:02:33.228	TRACE_LEVEL_INFORMATION	Connection established with client
2019/01/08-21:02:33.228	TRACE_LEVEL_INFORMATION	Connection completed, connection: 0xFFFFFA8009D890C0
2019/01/08-21:02:33.228	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectResponseCompleted Exit

This is the last (still working) Chinese ripoff-DS3 I currently possess and it connects as well

2019/01/09-19:39:23.848	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x01, Length: 4, PSM: 0x5053, SCID: 0x0040]
2019/01/09-19:39:23.858	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0000, SCID: 0x0040, Result: 0x0001, Status: 0x0000]
2019/01/09-19:39:23.858	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x01, Length: 8, DCID: 0x0040, SCID: 0x0040, Result: 0x0000, Status: 0x0000]
2019/01/09-19:39:23.858	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x01, Length: 8, DCID: 0x0040, Flags: 0x0000, Options: 0xFFFF0201]
2019/01/09-19:39:23.871	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 4, DCID: 0x0040, Flags: 0x0000, Options: 0x00001000]
2019/01/09-19:39:23.871	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/09-19:39:23.873	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x01, Length: 10, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
2019/01/09-19:39:23.880	>> L2CAP_Connection_Request [Code: 0x02, Identifier: 0x03, Length: 4, PSM: 0x5055, SCID: 0x0041]
2019/01/09-19:39:23.880	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0000, SCID: 0x0041, Result: 0x0001, Status: 0x0000]
2019/01/09-19:39:23.880	<< L2CAP_Connection_Response [Code: 0x03, Identifier: 0x03, Length: 8, DCID: 0x0041, SCID: 0x0041, Result: 0x0000, Status: 0x0000]
2019/01/09-19:39:23.880	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 8, DCID: 0x0041, Flags: 0x0000, Options: 0xFFFF0201]
2019/01/09-19:39:23.893	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x04, Length: 4, DCID: 0x0041, Flags: 0x0000, Options: 0x00001000]
2019/01/09-19:39:23.893	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x04, Length: 6, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/09-19:39:23.894	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 10, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0201]

DualShock 4 (Revision 1) connection sequence

2019/01/09-21:11:02.588	<< L2CAP_Connection_Request [Code: 0x02, Identifier: 0x02, Length: 4, PSM: 0x0001, SCID: 0x0040]
2019/01/09-21:11:02.597	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x02, Length: 8, DCID: 0x0040, SCID: 0x0040, Result: 0x0001, Status: 0x0002]
2019/01/09-21:11:02.599	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x02, Length: 8, DCID: 0x0040, SCID: 0x0040, Result: 0x0000, Status: 0x0000]
2019/01/09-21:11:02.599	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x03, Length: 8, DCID: 0x0040, Flags: 0x0000, Options: 0x04000201]
2019/01/09-21:11:02.610	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x03, Length: 10, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
2019/01/09-21:11:02.612	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x01, Length: 8, DCID: 0x0040, Flags: 0x0000, Options: 0x04000201]
2019/01/09-21:11:02.612	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x01, Length: 6, SCID: 0x0040, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/09-21:11:02.612	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 0, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:02.623	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 1, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:04.088	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 2, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:04.449	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 3, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:04.513	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 4, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:04.718	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x00, Length: 5, DCID: 0x350F, SCID: 0x1903]
2019/01/09-21:11:05.031	<< L2CAP_Connection_Request [Code: 0x02, Identifier: 0x04, Length: 4, PSM: 0x0011, SCID: 0x0041]
2019/01/09-21:11:05.069	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x04, Length: 8, DCID: 0x0041, SCID: 0x0041, Result: 0x0001, Status: 0x0002]
2019/01/09-21:11:05.091	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x04, Length: 8, DCID: 0x0041, SCID: 0x0041, Result: 0x0000, Status: 0x0000]
2019/01/09-21:11:05.091	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x05, Length: 8, DCID: 0x0041, Flags: 0x0000, Options: 0x02A00201]
2019/01/09-21:11:05.135	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x05, Length: 10, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
2019/01/09-21:11:05.156	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x02, Length: 8, DCID: 0x0041, Flags: 0x0000, Options: 0x02A00201]
2019/01/09-21:11:05.156	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x02, Length: 6, SCID: 0x0041, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/09-21:11:05.156	<< L2CAP_Connection_Request [Code: 0x02, Identifier: 0x06, Length: 4, PSM: 0x0013, SCID: 0x0042]
2019/01/09-21:11:05.192	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x06, Length: 8, DCID: 0x0042, SCID: 0x0042, Result: 0x0001, Status: 0x0002]
2019/01/09-21:11:05.199	>> L2CAP_Connection_Response [Code: 0x03, Identifier: 0x06, Length: 8, DCID: 0x0042, SCID: 0x0042, Result: 0x0000, Status: 0x0000]
2019/01/09-21:11:05.199	<< L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x07, Length: 8, DCID: 0x0042, Flags: 0x0000, Options: 0x02A00201]
2019/01/09-21:11:05.209	>> L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x07, Length: 10, SCID: 0x0042, Flags: 0x0000, Result: 0x0000, Options: 0x0201]
2019/01/09-21:11:05.212	>> L2CAP_Configuration_Request [Code: 0x04, Identifier: 0x03, Length: 8, DCID: 0x0042, Flags: 0x0000, Options: 0x02A00201]
2019/01/09-21:11:05.212	<< L2CAP_Configuration_Response [Code: 0x05, Identifier: 0x03, Length: 6, SCID: 0x0042, Flags: 0x0000, Result: 0x0000, Options: 0x0000]
2019/01/09-21:11:07.797	<< L2CAP_Disconnection_Request [Code: 0x06, Identifier: 0x08, Length: 4, DCID: 0x0040, SCID: 0x0040]
2019/01/09-21:11:07.801	>> L2CAP_Disconnection_Response [Code: 0x07, Identifier: 0x08, Length: 4, DCID: 0x0040, SCID: 0x0040]

Oof, code base growing rapidly

From top to bottom:

• Profile driver
• Filter driver
• Driver installation utility

Enum BTH - Microsoft Bluetooth Enumerator

Enum USB - Generic Bluetooth Radio

PlayStation 3 Peripherals Filter Driver

How the Heck do I get rid of the Advanced tab

Working on BthPS3Util

Creating a small command line utility for abstracting away the mess of creating filter device node, installing filter driver, enabling the filter and registering the service profile.

Bloody hell, my mind was not prepared to deal with a state machine handling two L2CAP channels with all those async stuff happening and the tons of error handling required. Time for my favorite part in what I call (dramatic music playing ) poke-in-the-dark-development:

1. think about the solution
2. code it
3. think about it again
4. realize it's flawed
5. revert changes
6. goto 1

Oddly enough I wasn't able to find an official way to get the remote device name from an incoming connection, just the MAC address. This isn't a showstopper but odd and annoying for device identification. Or am I missing something

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Oddly enough I wasn't able to find an official way to get the remote device name from an incoming connection, just the MAC address. This isn't a showstopper but odd and annoying for device identification. Or am I missing something

Wait a minute... if I got this right, calling IOCTL_BTH_GET_DEVICE_INFO returns a BTH_DEVICE_INFO_LIST containing BTH_DEVICE_INFO which can then be matched against address and contains a name member:

Name of the remote Bluetooth device, as reported by the device, encoded in UTF8. The user may have locally provided a display name for the remote Bluetooth device; that name is overridden, and does not appear in this member; it is accessible only with a call to the BluetoothGetDeviceInfo function.

Bingo! The name isn't a 100% safe to rely on in device identification compared to the MAC address, but it's the best shot. It's important to react differently depending on the device type (DualShock 3, Navigation Controller, Motion Controller or DualShock 4 a.k.a. Wireless Controller). This is how it's currently done in WireShock:

BD_ADDR_FROM_BUFFER(clientAddr, &buffer[3]);

ULONG length;

//
// Scan through rest of buffer until null-terminator is found
//
for (length = 1;
	buffer[length + 8] != 0x00
	&& (length + 8) < NumBytesTransferred;
	length++);

//
// Store remote name in device context
//
WireBusSetChildRemoteName(
	Device,
	&clientAddr,
	&buffer[9],
	length
);

switch (buffer[9])
{
case 'P': // First letter in PLAYSTATION(R)3 Controller ('P')
	WireBusSetChildDeviceType(
		Device,
		&clientAddr,
		DS_DEVICE_TYPE_PS3_DUALSHOCK
	);
	break;
case 'N': // First letter in Navigation Controller ('N')
	WireBusSetChildDeviceType(
		Device,
		&clientAddr,
		DS_DEVICE_TYPE_PS3_NAVIGATION
	);
	break;
case 'M': // First letter in Motion Controller ('M')
	WireBusSetChildDeviceType(
		Device,
		&clientAddr,
		DS_DEVICE_TYPE_PS3_MOTION
	);
	break;
case 'W': // First letter in Wireless Controller ('W')
	WireBusSetChildDeviceType(
		Device,
		&clientAddr,
		DS_DEVICE_TYPE_PS4_DUALSHOCK
	);
	break;
default:
	TraceEvents(TRACE_LEVEL_ERROR,
		TRACE_INTERRUPT,
		"Couldn't determine device type from remote name (%c)",
		buffer[9]
	);
	break;
}

I've discovered that a DS4 (Rev1) paired in PC-mode will also try to directly connect with PSM 0x11 and 0x13 in addition to the correct 0x01 and gets denied. It continues to work though; my best guess is that the controller simply tries if the Bluetooth host is a PS4 and changes its behavior accordingly. This is unfortunate for my profile driver, because now I need to know that it is a DS4, not a DS3, and deny the connection request because the filter will rewrite the PSMs as well. This rabbit hole...

Quite interesting research. So putting this into simple terms, the filter driver will pickup the DS4 and will interpret it's requests instead? Which is bad because the DS4 has bluetooth support already.

@daltz333 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Quite interesting research. So putting this into simple terms, the filter driver will pickup the DS4 and will interpret it's requests instead? Which is bad because the DS4 has bluetooth support already.

The filter is stupid and has no idea what kind of device is connecting, it looks for Protocol/Service Multiplexer values 0x11 (HID Control) and 0x13 (HID Interrupt) and patches them to artificial values the profile driver listens on. So now the profile driver is in charge of handling the connection requests. The profile driver needs to know what kind of device connects because anything else than the PS3 peripherals could in theory use those PSMs as well. Now we also know that the DS4 tries them as well for whatever reason. It doesn't need to because it has a valid SDP record but I guess it does it to "poke" the Bluetooth host and switches to native PS4 mode if the PSMs get accepted. Who knows what would happen then.

Papers, please

2019/01/20-16:50:29.960	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/20-16:50:29.960	TRACE_LEVEL_INFORMATION	++ deviceInfoList.numOfDevices: 2
2019/01/20-16:50:29.960	TRACE_LEVEL_INFORMATION	++ Device 0 address ACFD93095C20, name: Wireless Controller
2019/01/20-16:50:29.960	TRACE_LEVEL_INFORMATION	++ Device 1 address AC7A4D2819AC, name: PLAYSTATION(R)3 Controller
2019/01/20-16:50:29.981	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from AC7A4D2819AC arrived
2019/01/20-16:50:29.981	TRACE_LEVEL_INFORMATION	++ deviceInfoList.numOfDevices: 2
2019/01/20-16:50:29.981	TRACE_LEVEL_INFORMATION	++ Device 0 address ACFD93095C20, name: Wireless Controller
2019/01/20-16:50:29.981	TRACE_LEVEL_INFORMATION	++ Device 1 address AC7A4D2819AC, name: PLAYSTATION(R)3 Controller
2019/01/20-16:50:29.993	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest

We got the name! Delightful

Some more hardening and error handling, that will be all for today

2019/01/20-18:11:22.457	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/20-18:11:22.457	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/20-18:11:22.457	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/20-18:11:22.457	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D)
2019/01/20-18:11:22.457	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/20-18:11:22.457	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/20-18:11:23.072	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/20-18:11:23.072	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry
2019/01/20-18:11:23.072	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/20-18:11:23.093	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/20-18:11:23.093	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from AC7A4D2819AC arrived
2019/01/20-18:11:23.093	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/20-18:11:23.093	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/01/20-18:11:23.093	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/20-18:11:23.093	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit

I'm feeling a cold creeping up on me but nevertheless managed to utilize enough brain power to implement resource cleanup on disconnect without a single BSOD!

--- DS3 connecting ---
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/24-20:39:11.096	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/24-20:39:11.096	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/24-20:39:11.096	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/24-20:39:11.112	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from AC7A4D2819AC arrived
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Entry
2019/01/24-20:39:11.112	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	L2CAP_PS3_SendConnectResponse Exit (STATUS_SUCCESS (0x00000000))
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:11.112	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/24-20:39:11.121	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x4, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:11.121	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
2019/01/24-20:39:11.121	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
--- DS3 connected ---

--- DS3 disconnecting (by holding PS button for 10 seconds) ---
2019/01/24-20:39:35.193	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:35.193	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFFFA80073F9CE0]
2019/01/24-20:39:35.193	TRACE_LEVEL_VERBOSE	++ HID Interrupt Channel 0xFFFFFA80073F9CE0 disconnected
2019/01/24-20:39:35.193	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFFFA800775E170]
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	++ HID Control Channel 0xFFFFFA800775E170 disconnected
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	ClientConnections_RemoveAndDestroy Entry (Context: 0xFFFFFA8007488780)
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/24-20:39:35.196	TRACE_LEVEL_VERBOSE	EvtClientConnectionsDestroyConnection Entry
2019/01/24-20:39:35.619	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:35.619	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/24-20:39:35.619	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFFFA8007488780)
2019/01/24-20:39:35.619	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
--- DS3 disconnected ---

'till next time

Device identification and connection drop on error/incompatibility implemented and working

2019/01/25-18:16:35.587	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/25-18:16:35.587	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/25-18:16:35.587	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/01/25-18:16:35.588	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D), dropping connection
2019/01/25-18:16:35.588	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Entry
2019/01/25-18:16:35.588	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/01/25-18:16:35.588	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Exit
2019/01/25-18:16:35.588	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Exit
2019/01/25-18:16:35.588	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/01/25-18:16:36.188	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/01/25-18:16:36.188	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/01/25-18:16:36.188	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/01/25-18:16:36.188	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/01/25-18:16:36.188	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA8008FDB5B0)
2019/01/25-18:16:36.188	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/01/25-18:16:36.188	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))

Marvelous terrible quality video demonstrating that DS4 and DS3 can live together in peace on the default Bluetooth host driver:

Youtube Video

In typical USB-fashion the darn plug didn't want to go into the socket in one go and the room didn't have enough light to combat the bright screen causing the camera to adjust exposure so it all went a bit too dark

What's happening in the video:

• Bluetooth host USB dongle gets plugged in, default Window driver, filter and profile driver get loaded
• DS4 gets paired in PC-mode and works as expected
• DS3 gets powered on by tap on PS button and connects (there is no output report sent yet so the LEDs will keep flashing although it has connected successfully)
• DS4 continues to work unimpressed by second device, so no interference
• DS3 gets force-shut-off by holding PS button for around ten seconds
• DS4 continues to work after DS3 has left the building

So far not so shabby!

Managed to send it the first output report, now the LEDs stay bright on

2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/01-02:39:55.177	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/01-02:39:55.177	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D), dropping connection
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Entry
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Exit
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Exit
2019/02/01-02:39:55.177	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/01-02:39:55.757	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from AC7A4D2819AC arrived
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/01-02:39:55.757	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA8007378CA0)
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/02/01-02:39:55.757	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/01-02:39:55.764	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Entry
2019/02/01-02:39:55.764	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/02/01-02:39:55.764	TRACE_LEVEL_INFORMATION	HID Control Channel connection established
2019/02/01-02:39:55.764	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Exit
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/01-02:39:55.772	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from AC7A4D2819AC arrived
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/01-02:39:55.772	TRACE_LEVEL_INFORMATION	++ Device AC7A4D2819AC name: PLAYSTATION(R)3 Controller
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA8007378CA0)
2019/02/01-02:39:55.772	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/01-02:39:55.781	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x4, Context: 0xFFFFFA8007378CA0)
2019/02/01-02:39:55.781	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
2019/02/01-02:39:55.781	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/01-02:39:55.784	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Entry
2019/02/01-02:39:55.784	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/02/01-02:39:55.784	TRACE_LEVEL_INFORMATION	HID Interrupt Channel connection established
2019/02/01-02:39:55.784	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Entry
2019/02/01-02:39:55.784	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Exit
2019/02/01-02:39:55.784	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Exit
2019/02/01-02:39:55.785	TRACE_LEVEL_VERBOSE	Control transfer request completed with status STATUS_SUCCESS (0x00000000)

Biggest struggle in this project so far

Couldn't fall asleep last night, implemented bus enumerator instead:

Youtube Video

What's going on in the video: once the connection of both HID Control and Interrupt channels has been established, the wonderful KMDF bus driver API kicks in and spawns a new PNP device:

WDF_CHILD_IDENTIFICATION_DESCRIPTION_HEADER_INIT(
        &pdoDesc.Header,
        sizeof(PDO_IDENTIFICATION_DESCRIPTION)
    );

pdoDesc.RemoteAddress = ClientConnection->RemoteAddress;
pdoDesc.DeviceType = ClientConnection->DeviceType;

//
// Invoke new child creation
// 
status = WdfChildListAddOrUpdateChildDescriptionAsPresent(
	WdfFdoGetDefaultChildList(ClientConnection->DevCtxHdr->Device),
	&pdoDesc.Header,
	NULL
);

In order to de-clutter the profile/bus driver I decided to outsource the device-specific logic into one or more additional function drivers, introducing IOCTLs to fetch data from and send to the PDOs without having to deal with Bluetooth-specific paradigms at all. I've introduced artificial GUID-based hardware IDs for every distinct device:

• DS_DEVICE_TYPE_SIXAXIS - SIXAXIS or DualShock 3 compatible (including 3rd party controllers)
• DS_DEVICE_TYPE_NAVIGATION - PlayStation Move Navigation Controller
• DS_DEVICE_TYPE_MOTION - PlayStation Move Motion Controller
• DS_DEVICE_TYPE_WIRELESS - DualShock 4 Revision 1 or 2 Wireless Controller

On a personal note; I'm quite pleased about the pacing here, implementing the bus logic was done almost entirely from memory and implemented once again without crashing the test host

A lot of progress was made today. Nothing much to present yet but I've basically started to design and implement the interface that will be used to talk to the exposed PDOs via own function driver. This causes the code base for the profile driver remain encapsulated for Bluetooth related stuff only. Higher level functions (HID mini-driver, LED, Rumble, ...) will then be implemented by one or more individual function drivers latching onto the PDOs.

Cheers

Wrapped all necessary driver (un-)installation tasks in a small self-contained tool and finished proper error handling:

This tool can then assist a setup in automating the installation and also making test installations more bearable

What happens in the picture for each line:

• BluetoothSetLocalServiceInfo is invoked which causes bthenum to spawn a PDO for the profile driver to latch onto
• Bluetooth profile driver gets installed in driver store and device driver installation for newly spawned PDO gets kicked off
• bthusb lower filter driver service (BthPS3PSM) gets created
• BthPS3PSM gets added as lower filter driver for GUID_DEVCLASS_BLUETOOTH device class
• Same action is invoked again, leading to a different response
• Service creation is invoked again, failing because it's already registered

That'll be all for today, folks!

It's communicating!

I've managed to quickly hack together an ugly demo function driver for the SIXAXIS PDO in under an hour and test it with only two crashes

_Use_decl_annotations_
VOID
OutputReport_EvtTimerFunc(
    WDFTIMER  Timer
)
{
    WDFDEVICE device = WdfTimerGetParentObject(Timer);
    WDFIOTARGET ioTarget = WdfDeviceGetIoTarget(device);
    PDEVICE_CONTEXT devCtx = DeviceGetContext(device);

    TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DEVICE, "%!FUNC! Entry");

    static UCHAR G_Ds3HidOutputReport[] = {
    0x52, 0x01, 0x00, 0xFF, 0x00, 0xFF, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x1E, 0xFF, 0x27, 0x10, 0x00,
    0x32, 0xFF, 0x27, 0x10, 0x00, 0x32, 0xFF, 0x27,
    0x10, 0x00, 0x32, 0xFF, 0x27, 0x10, 0x00, 0x32,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00
    };

    static BOOLEAN toggle = FALSE;

    toggle = !toggle;
    G_Ds3HidOutputReport[11] = (toggle) ? 0x02 : 0x04;

    PBTHPS3_HID_CONTROL_WRITE controlWrite;
    NTSTATUS status;

    WDF_MEMORY_DESCRIPTOR  MemoryDescriptor;
    WDFMEMORY  MemoryHandle = NULL;
    status = WdfMemoryCreate(NULL,
        NonPagedPool,
        'aylB',
        sizeof(BTHPS3_HID_CONTROL_WRITE),
        &MemoryHandle,
        &controlWrite);

    BTHPS3_HID_CONTROL_WRITE_INIT(controlWrite);

    controlWrite->BufferLength = 0x32;
    controlWrite->Buffer = ExAllocatePoolWithTag(
        NonPagedPoolNx,
        0x32,
        'aylB'
    );
    RtlCopyMemory(controlWrite->Buffer, G_Ds3HidOutputReport, 0x32);

    WDF_MEMORY_DESCRIPTOR_INIT_HANDLE(&MemoryDescriptor,
        MemoryHandle,
        NULL);

    status = WdfIoTargetSendInternalIoctlSynchronously(
        ioTarget,
        NULL,
        IOCTL_BTHPS3_HID_CONTROL_WRITE,
        &MemoryDescriptor,
        NULL,
        NULL,
        NULL
    );

    ExFreePoolWithTag(controlWrite->Buffer, 'aylB');

    if (!NT_SUCCESS(status)) {
        TraceEvents(TRACE_LEVEL_ERROR,
            TRACE_DEVICE,
            "WdfIoTargetSendInternalIoctlSynchronously failed with status %!STATUS!",
            status
        );
        return;
    }

    WdfTimerStart(devCtx->OutputReportTimer, WDF_REL_TIMEOUT_IN_MS(0x01F4));

    TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DEVICE, "%!FUNC! Exit");
}

This is a timer callback function getting called around every 500 ms and cycling through LED 1 and 2 by submitting an output report to the HID Control endpoint via IOCTL_BTHPS3_HID_CONTROL_WRITE. The driver is very minimal, inefficient with memory handling and horribly named but for a demonstration just perfect

Next I'm gonna try to read from it

Turns out reading from the HID interrupt channel the right way is a bit more challenging than I expected. Unfortunately there's no Bluetooth equivalent of the continuous reader for USB pipes in WDF so you've to implement that thing yourself. There are reference implementations available but they're so "ripped apart" and all over the place I'll instead try to write it from scratch to better understand what's happening. Maybe I get somewhere today, we'll see

There we go

2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoInternalDeviceControl Entry
2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfIoQueueIoInternalDeviceControl Entry
2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	bufferLength: 50
2019/02/10-17:52:51.885	TRACE_LEVEL_VERBOSE	brb->BufferSize: 50, brb->RemainingBufferSize: 0
2019/02/10-17:52:51.885	TRACE_LEVEL_INFORMATION	A1 01 00 00 00 00 00 7A 81 80 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 FF CD 00 01 33 00 77 00 40 01 FA 01 ED 01 91 00 05 
2019/02/10-17:52:51.885	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoInternalDeviceControl Exit

What threw me off for quite a few hours was the weird behavior of the RemainingBufferSize member of the _BRB_L2CA_ACL_TRANSFER structure, which was increasing fast to values way higher than the buffer I supplied could hold. Turns out this field is not talking about the Buffer member the caller supplies but the internal buffer of the Bluetooth host which tells you how many bytes have already come in from the remote device and are available to be read by further calls with that same BRB. I don't think the reference code I had a peek at did take that into account as this value was subtracted from BufferSize which could lead to a negative value resulting in

Now that that's sorted out off to cleaning up this mess and looking for leaking memory

Going the extra mile today: testing the PS Move Navigation controller Connection established:

2019/02/10-18:32:19.445	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/10-18:32:19.445	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 70401E341 arrived
2019/02/10-18:32:19.445	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/10-18:32:19.446	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D), dropping connection
2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Entry
2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Exit
2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Exit
2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/10-18:32:20.247	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 70401E341 arrived
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/10-18:32:20.247	TRACE_LEVEL_INFORMATION	++ Device 70401E341 name: Navigation Controller
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA80074DE0C0)
2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/10-18:32:20.497	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Entry
2019/02/10-18:32:20.497	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/02/10-18:32:20.497	TRACE_LEVEL_INFORMATION	HID Control Channel connection established
2019/02/10-18:32:20.497	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Exit
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
2019/02/10-18:32:20.689	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from 70401E341 arrived
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/02/10-18:32:20.689	TRACE_LEVEL_INFORMATION	++ Device 70401E341 name: Navigation Controller
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA80074DE0C0)
2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/10-18:32:20.783	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x4, Context: 0xFFFFFA80074DE0C0)
2019/02/10-18:32:20.783	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
2019/02/10-18:32:20.783	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Entry
2019/02/10-18:32:20.824	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/02/10-18:32:20.824	TRACE_LEVEL_INFORMATION	HID Interrupt Channel connection established
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Entry
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Exit
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Exit
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Entry
2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Exit

And there we have the HID Input Report in the function driver

2019/02/10-18:34:23.749	TRACE_LEVEL_INFORMATION	InputReport_EvtTimerFunc Entry
2019/02/10-18:34:23.757	TRACE_LEVEL_INFORMATION	A1 01 00 00 00 00 00 80 80 7D 85 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 03 14 FF C2 00 00 23 D6 77 00 40 02 00 02 04 01 A3 01 FF 
2019/02/10-18:34:23.757	TRACE_LEVEL_INFORMATION	InputReport_EvtTimerFunc Exit

Alright, time to properly polish and fix power management.

I've implemented dropping all connections in case of bthenum surprise removal (unplugging the USB Bluetooth dongle without warning), freeing memory and instructing child device (PDO) removal. This works well and allows unloading the driver, so no dangling objects here. But as soon as the function driver attaches, everything stalls on surprise removal. I haven't yet had the time to debug/implement it but I can document a few assumptions to help me later when I pick it up again.

• EvtWdfIoQueueIoInternalDeviceControl sends BRBs synchronously out of convenience, this probably isn't the brightest idea, will adjust that to asynchronous
• PDO might be missing PNP/Power capabilities
• Queue I/O stop callback isn't invoked
• Maybe implement self-managed I/O flush callback?

I bet it's an easy fix and I'm just overthinking the issue. Will pick up development again in a few days

Surprise removal power-down sequence fixed!

Two things had to be done (properly):

• In EVT_WDF_IO_QUEUE_IO_INTERNAL_DEVICE_CONTROL I've converted every BRB submission to asynchronous I/O which avoids clogging up the queue dispatch callback and also slightly improved performance and resource usage (memory for request and payload buffer)
• EVT_WDF_IO_QUEUE_IO_STOP calls WdfRequestCancelSentRequest to complete pending requests sent to the I/O target (in this case our Bluetooth parent FDO)

Another step closer to finishing and hardening the profile/bus driver

Goddammit, I managed to make bthport.sys leak memory

Time for code review!

Aha! It only happens when I send data to the HID Control Channel, how interesting We'll see about that...

Seriously, how did I do that

Pool tag details:

BTHP - bthport.sys  - Bluetooth port driver (generic)
HCIT - bthport.sys  - Bluetooth port driver (HCI)

Now if the symbols could download faster than over 56k I could actually see more

Better graph, still no clue

Ha, found it! Now that's more like it:

Purple is non-paged memory from HCI-specific pool now only slightly jittering up and down as expected. Green is the BTHP pool which is now steady as well. The uneven bumps are probably owed to timing in the driver and probably latency on the radio link.

So what was the issue? Well, previously I was only writing to the HID Control Channel (periodically) because that's how the HID Output Report travels to the remote device. Now since I couldn't find any issues with my memory handling in my own drivers I was starting to experiment and implemented reading from the control channel (where there shouldn't be any data coming back because the DS3 sends data over the HID Interrupt Channel) as well and look at that: with every packet I send out there's one byte of "response" available to read as well! The content is always a solid 0x00 but still, this was allocating and holding memory in the lower sections of bthport.sys and the reason for the rise in non-paged memory usage. I'm now also periodically reading and therefore "emptying" the control channel and now it's not growing anymore. Nice!

Time for a break

Guess some sort of Writer's Block got me, but for coding. No worries though, will do something else then until the spirits are up for it again

Cheers

I've currently "interrupted" further coding with building my WHQL lab. The progress on it gets its own thread here but since my Windows 7 test boxes are ready I'll throw the current revision of the profile driver into it and see what happens

Can't wait to connect my Ps3 controller via bluetooth to pc without installing malicious software (it's this project all about this right?, if yes, when it will be released? )

@epikvigem pretty much sums it up, yeah This set of drivers will allow you to use the popular PS3 peripherals (DualShock 3, Navigation & Move Controllers) transparently with little overhead on Windows 7 up to 10.

As for the estimated release schedule... If the current pace stays where it is I aim for early or mid May?

Cheers

HCK had its run over night on the profile driver and look how happy it is

Next I have to polish and test the filter driver and extend it with a few management features (like turning it on or off from user-land).

@nefarius this looks awesome! Really looking forward to seeing this in production! Is there anything we as a community can do or provide to assist your work? Beta testing, experiment with various BT dongles/pads, or just show interest in your product? What kind of licensing are you thinking about once this is ready? Propriety paid/free, open source and all its variations, dual - community version open source (without binaries) VS paid WHQL certified?

@Locksmith pardon the delay, I wanted to answer this in detail as it contains a lot of interesting and valid questions.

Community involvement

I will be getting to a stage where the full stack can be tested and I would greatly appreciate it if I get a few owners of those obviously "fake" and aftermarket DualShock "PANHAI" controllers since I can't order them in my country and back in SCP-days a rather large demographic was interested in getting them to work as they typically only cost around 10$. I'm not a fan of those personally but if they work on the stack with ease, be my guest As I own the genuine Sony hardware I can guarantee a 100% compatibility for those obviously. Just a heads-up: I won't give out production-signed binaries to beta testers anymore though as that's irresponsible. So anybody interested would be required to put his or her machine into test mode. Usually not a big deal but I've heard that a few anti-cheat and DRM solutions out there won't let you launch certain games anymore until reverted.

Dongle compatibility shouldn't be much of an issue anymore as the vendor software stack is kept in place and isn't touched anymore (unlike SCP) so e.g. Intel Wireless cards will keep operating with the Intel vendor driver. Tests welcome though nonetheless.

Last but not least I ofc. welcome interest in my post-apocalypticSCP shenanigans I've launched into this mess out of personal motivation; getting comfortable with yet another kernel-mode driver, the Windows Bluetooth Driver Interface, WHQL-fun and maybe finally getting a finished plug-and-play solution so I can visit my couch again and play Castlevania A lot of what's happening here currently is straight out research and development. As a lot of people are apparently not understanding (or accepting) what "work in progress" means I keep "advertising" for the forum etc. to a minimum as long as there's not enough resources for me to research, develop, give support, regularly update news etc. This doesn't mean I want to stay in my own bubble here, I welcome anybody interested but in return I expect acceptance if things don't quite go according to plan.

Licensing

Despite a few "hiccups" I've had with larger corporations taking my stuff being a bit clumsy in the past I'm still a big advocate and believer in open-source. First and foremost because I'd probably not be in this "business" of dealing with gaming peripherals if the mad lad creating SCP hadn't open-sourced his or her work plus all of the other fabulous projects and samples I profited of by studying the sources. This also includes non-Windows sources like bits and pieces in the Linux kernel or Arduino projects. So I'll definitely open-source this stack as well once I tag it production-ready.

Now one might ask why this time I didn't go for GitHub from the very beginning but use a private Git repository instead. It makes developing the back-doors so much easier! Jokes aside, once again this is another measure I had to take to protect myself from idiocy. What I've noticed over the years is that non-developers who find something interesting on GitHub usually ignore the README and other helpful resources completely, get confused because there is no "download EXE here now" button and then come haunt and annoy me and my team with questions that could've been avoided from the very start. I have no problem with answering questions but if I get used as a search engine replacement I take that as a personal offense as you clearly show me that you don't value my time. Phew, that went sour fast

Back to licensing. With upcoming releases I'm gonna include an EULA to both protect myself (you know, warranty, haha) and probably place some restrictions on it regarding commercial use. Maybe dual-licensing it. Again, there are reasonable motivations behind it. To private individuals I wanna ensure all the freedom and openness as possible as that's the target demographic. Corporations though are dumb. What do I mean by that? Well, just forking a driver, re-branding and releasing it (not that this has happened before, huehuehue) is a horrible practice. Drivers need maintenance and the knowledge on how to maintain them properly. If they cause an issue on an end-users machine it needs to be diagnosed and addressed. Can they provide that? No, they'll conveniently send them to me who's expected to give free support and fix everything. Nope, get fucked, GPL and other restrictions it will be for you then. I haven't settled on the best solution there yet but I'm working on ideas that benefit all sides as much as possible.

Regarding WHQL... Binaries without it aren't really worth it nowadays so it's either just the sources and have fun or a properly signed binary. Could I sell it? Eh. Would it sell? Eh. Would I take a few Schekels if offered? Oh, absolutely, the bills haven't stopped I need to figure this out. Bring back donations? Eh. Maybe they'll flourish again if a finished attractive product is released? So many questions, so little time. We'll figure it out

I think I've got everything out I wanted to address, pardon the wall of text

Cheers

Meh, HCK tests on Windows 8.1 do a bit more in-depth Bluetooth testing it seems and it's complaining that I've left out some I/O handlers I thought I don't need. Well, can't argue against the machine so back to hacking and fixing

There we go!

Another night of wasting electricity done but the results at least are satisfying

Next I'll test with children connected. Not sure how it'll react since the power and sleep tests will most certainly disconnect them from the Bluetooth host but we'll see!

I was bitching a lot about the Hardware Lab Kit and debugging utilities in general in the past but to perfectly honest; the more I become familiar with them and overcome their quirks the more I appreciate the feedback they provide.

Like for example; I've tried to connect a DS3 while the profile driver is running under Driver Verifier (which in short means that a strong rule-set applies triggering bugs that might have gone under) on Windows 8.1 and it crashed with:

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffff80000003, The exception code that was not handled
Arg2: fffff801f61cd3c0, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 7efefefefeff3252, Parameter 1 of the exception

Once in WinDbg with the symbols loaded we get a nice "stack trace":

STACK_TEXT:  
... : nt!KeBugCheckEx
... : nt!KiFatalExceptionHandler+0x22
... : nt!RtlpExecuteHandlerForException+0xd
... : nt!RtlDispatchException+0x1a5
... : nt!KiDispatchException+0x18d
... : nt!KiExceptionDispatch+0xc2
... : nt!KiBreakpointTrap+0x2dc
... : nt!DbgBreakPoint+0x1
... : Wdf01000!FxIoTargetSendIoctl+0x282da
... : Wdf01000!imp_WdfIoTargetSendIoctlSynchronously+0x48
... : BthPS3!L2CAP_PS3_HandleRemoteConnect+0x16a [e:\development\gogs\bthps3\bthps3\l2cap.c @ 49] 
... : BthPS3!BthPS3_IndicationCallback+0x9c [e:\development\gogs\bthps3\bthps3\bluetooth.c @ 552] 
... : bthport!L2CapInt_ProcessL2capConnectReq+0x40b
... : bthport!L2CapInt_ProcessSignallingPacket+0x45f
... : bthport!L2CapInt_ProcessReadBip+0x13a
... : bthport!HCI_ProcessAclReadBip+0x661
... : bthport!HCI_ProcessAclRead+0x2a8
... : bthport!HCI_ProcessMpBip+0x92
... : bthport!BTHPORT_RecvMpBip+0x41
... : BTHUSB!BthUsb_ReadTransferComplete+0x18d
... : BTHUSB!UsbWrapWorkRoutine+0x18d
... : BTHUSB!UsbWrapInterruptReadComplete+0x1d3
... : nt!IovpLocalCompletionRoutine+0x174
... : nt!IopfCompleteRequest+0x2ee
... : nt!IovCompleteRequest+0x1d7
... : Wdf01000!FxRequest::CompleteInternal+0x23c
... : Wdf01000!imp_WdfRequestComplete+0x8c
... : BthPS3PSM!UrbFunctionBulkInTransferCompleted+0x107 [e:\development\gogs\bthps3\bthps3psm\filter.c @ 233] 
... : Wdf01000!FxRequestBase::CompleteSubmitted+0x459
... : Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x162
... : nt!IopUnloadSafeCompletion+0x49
... : nt!IovpLocalCompletionRoutine+0x174
... : nt!IopfCompleteRequest+0x2ee
... : nt!IovCompleteRequest+0x1d7
... : USBPORT!USBPORT_Core_iCompleteDoneTransfer+0xa02
... : USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x21c
... : USBPORT!USBPORT_Core_UsbIocDpc_Worker+0x238
... : USBPORT!USBPORT_Xdpc_Worker_IocDpc+0x1fe
... : nt!KiExecuteAllDpcs+0x1b0
... : nt!KiRetireDpcList+0xd7
... : nt!KiIdleLoop+0x5a

Alrighty, so line 49 in the function L2CAP_PS3_HandleRemoteConnect in l2cap.c of the driver BthPS3 is triggering the fault. Let's see what's there:

Ah, an inline function! What does it contain that might bomb? I have a suspicion (mostly because it's hinted in the stack trace )...

Let's have a look at the docs of WdfIoTargetSendIoctlSynchronously and check out the requirements section:

IRQL PASSIVE_LEVEL

Hm, but our L2CAP callback is invoked at PASSIVE_LEVEL, right? Let's throw in some tracing and have another run:

2019/03/10-10:46:19.023	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Entry (Low (0x00))
2019/03/10-10:46:19.023	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry (Low (0x00))
2019/03/10-10:46:19.038	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Entry (DPC (0x02))
2019/03/10-10:46:19.038	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry (DPC (0x02))

Hey! The second call isn't at PASSIVE_LEVEL, that's DISPATCH_LEVEL! How dare you! Oh wait, the docs, check the docs:

IRQL Developers should code this function to operate at either IRQL = DISPATCH_LEVEL (if the callback function does not access paged memory), or IRQL = PASSIVE_LEVEL (if the callback function must access paged memory)

Ouch! How evil! So that can totally happen and !wdfkd.wdflogdump gives clear insights:

1: kd> !wdfkd.wdflogdump BthPS3
...
37: FxVerifierCheckIrqlLevel - Called at wrong IRQL; at level 2, should be at level 0
---- end of log ----

Right, so this would've fallen under the radar if it didn't bomb in the lab. Thanks, WHQL Onward with the fixes!

How future proof is this filter solution? Do you think it is possible for Windows to make such a change in a update that could break it or you think that is unlikely or just straight up impossible unless windows change in a fundamental way?

Sorry if this is no place to ask or if my question does not make much sense. I am no developer/coder in any meaningful way, but I know just enough about coding to understand your posts here and I find it really interesting to know how this actually works. I would really appreciate to hear your thoughts on this with some insight on why and how windows could or couldn't break this in the near future.
Also, thanks for your work on the ScpToolKit and on maintaining this posts on the development! I find myself refreshing this page many times a day just to see your explanations on how you are making your way through this.

@kirian said in Bluetooth Filter Driver for DS3-compatibility - research notes:

How future proof is this filter solution? Do you think it is possible for Windows to make such a change in a update that could break it or you think that is unlikely or just straight up impossible unless windows change in a fundamental way?

Heya! This is actually the most future-proof you can get. Apart from the filter driver which proxies the forbidden PSMs the profile/bus driver uses a standard DDI (Device Driver Interface) provided by Microsoft which exists since (at least) Windows XP and is documented fairly well (see here and here). Microsoft is the grand master of backwards compatibility so I expect this to last quite a fair bit without the need of updates once it's deemed stable.

@kirian said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Sorry if this is no place to ask or if my question does not make much sense. I am no developer/coder in any meaningful way, but I know just enough about coding to understand your posts here and I find it really interesting to know how this actually works. I would really appreciate to hear your thoughts on this with some insight on why and how windows could or couldn't break this in the near future.

Perfectly fine to ask here, this thread isn't meant to be only fed by myself, it's just my chaotic attempt of Rubber Duck Debugging and leaving a trail of insights on this "black magic" in kernel land Research and development as I like to call it.

I mean as far as the profile driver goes since it's a common practice to write profile drivers (well, probably not anymore because literally any standard device has one already) and the API is "official" and not some binary patching nonsense I'm pretty confident that this will outlive at least SCP

As for the PSM proxy... That's a bit of a risky move because I'm shipping around a function that was probably designed with a meaningful goal in mind and here I walz in and build a bridge across the forbidden river We will see, I guess

Also this method is far more likely to pass WHQL as I don't have to run the whole test battery directly against the USB device itself since the original driver is kept in place. With AirBender/WireShock I'd probably get a few dirty looks when I submit an INF file with a couple of dozen Hardware IDs which aren't mine to the Microsoft Portal Plus the user gets to keep all of their other Bluetooth devices connected, isn't that lovely

@kirian said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Also, thanks for your work on the ScpToolKit and on maintaining this posts on the development! I find myself refreshing this page many times a day just to see your explanations on how you are making your way through this.

Glad to hear I'm not only feeding my echo chamber Yeah, SCP's kind of my Dark Ages, it changed me in a lot of ways. Thanks for sticking around and showing interest

Cheers

Hm, disabling/shutting down the profile device causes crashes due to referencing freed memory. Next challenge is to trace along the whole connection/disconnection state machine and identify race conditions and whatnot

Let's welcome this new week by finishing a major bug fix: properly hardening the shutdown sequence to disconnect remote devices and free resources afterwards

Now entering hibernation

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Now entering hibernation

I really liked that one I registered to the forum just to reply to this...

Now getting serious, I've been following this topic, let me tell you that is awesome. I was a programmer myself when I was young, like 20 years ago, nothing like this, mostly enterprise application, databases and stuff, so I have a fair idea of the whole development process thing. This thread has been very interesting to follow, I didn't know how many things got involved in developing drivers and stuff related to hardware, very interesting.
Also, your previous post about hunting the bug related to the crash when device got disabled, it got me thinking in other things that could happen that could be related...

What happens when

1. The controller is moved out of range of the bluetooth receiver
2. The bluetooth receiver is disabled in the Device Manager (eg. if the receiver is embedded in a wifi card like the Intel ones on laptops)
3. The bluetooth receiver is disconnected from the host (eg. the receiver it's a USB dongle type)
4. If the controller get connected to host via USB cable while operating/connected via Bluetooth protocol, do it still operates or got it disconnected???
5. Does the controller start to charge its internal battery when is connected to host via USB cable?

I'm sure you already considered this scenarios, but I got curious about the answer to this events.
Anyway, let thank your for your effort in this, I really appreciate it.
It's really amazing to see that somebody got the time, knowledge and motivation to write this. In other OS like linux, this works out-of-the-box, also on NVidia Shield TV, but on windows it's disappointing to have to resort to third-party solutions to be able use our gamepads properly.

Also, what is the HARDWARE id that get reported to OS when the PS3 controllers are connected via this driver?

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Now getting serious, I've been following this topic, let me tell you that is awesome. I was a programmer myself when I was young, like 20 years ago, nothing like this, mostly enterprise application, databases and stuff, so I have a fair idea of the whole development process thing. This thread has been very interesting to follow, I didn't know how many things got involved in developing drivers and stuff related to hardware, very interesting.

Welcome, mate I've been trying to steer my career towards programming as a full-time profession but so far that hasn't really worked so I went back to doing everything the way I like and devote time to device driver development. Not my loss so far I struggled a lot in the past while developing the other projects and found this style of "blogging" to be a good way to both reflect on what I've been doing and as a reference and timeline for myself and other people interested. Sounds like it's a good strategy.

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Also, your previous post about hunting the bug related to the crash when device got disabled, it got me thinking in other things that could happen that could be related...
What happens when

Thanks for participating, let's go through the points one by one:

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

The controller is moved out of range of the bluetooth receiver

Then after a certain timeout the host driver (the one which controls the Bluetooth host device, a.k.a. "stock driver") will initiate a disconnect sequence and notifies the profile driver that the device is gone and now my clean-up code takes over. So far this case is handled properly. Should test it though

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

The bluetooth receiver is disabled in the Device Manager (eg. if the receiver is embedded in a wifi card like the Intel ones on laptops)

That's a typical power down event and since the profile driver is a child of the bthport.sys which then gets unloaded it receives shutdown indication as well and needs to dispose all connections and free memory before unloading the profile driver. So far this is handled already.

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

The bluetooth receiver is disconnected from the host (eg. the receiver it's a USB dongle type)

This case is called "surprise removal" and is also handled. When the parent is gone, the whole stack gets demolished. The profile children (PDOs) get removed, the profile driver enters clean-up and unloads, then the stock drivers unload. This is also implemented and tested.

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

If the controller get connected to host via USB cable while operating/connected via Bluetooth protocol, do it still operates or got it disconnected???

This is in fact an absurd case because the SIXAXIS/DS3 does not disconnect from Bluetooth when connected to USB while also connected wireless. That's a scenario I haven't tackled yet

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Does the controller start to charge its internal battery when is connected to host via USB cable?

Yes, despite all the BS and false information you find on the web there is no special driver required for the controller to charge via a standard 500 mA USB outlet. It also charges with a simple mobile phone charger, if it doesn't it has a hardware issue, not a software one. It does report battery charge level via software though on both USB and Bluetooth.

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

I'm sure you already considered this scenarios, but I got curious about the answer to this events.

I try to think of all aspects, especially because I wanna get this through WHQL so the quality and robustness has to be stellar

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Anyway, let thank your for your effort in this, I really appreciate it.
It's really amazing to see that somebody got the time, knowledge and motivation to write this. In other OS like linux, this works out-of-the-box, also on NVidia Shield TV, but on windows it's disappointing to have to resort to third-party solutions to be able use our gamepads properly.

Thanks, I might have just slipped into insanity without noticing Seriously though, it's been quite the challenge getting this and real-life obstacles handled in one go but as I'm adapting my life to support this stuff I might be able to keep this rodeo going until production-ready Linux has the advantage of the open kernel and contributors have added the Sony-specific customization a long time ago. On Windows you need to play after the rules of Microsoft. And dance with the devil in kernel-land where the forbidden fruits grow and magic can be found even to this day!

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Also, what is the HARDWARE id that get reported to OS when the PS3 controllers are connected via this driver?

I created some custom, GUID-based Hardware IDs the function drivers will use in the future.

Hope I got everything, cheers!

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Hope I got everything, cheers!

Wow, I'm really impressed... I'm pretty sure that I'm going to use this driver when it get released intro production.
I only regret having bought a Mayflash Wireless Adapter like 3-4 months ago to use my SIXAXIS/DS3 wireless without having to sacrifice the bluetooth receiver on a PC that I use to play retro games. I needed to use a wireless headphones to play at night, so that's why I needed the bluetooth device on the host working with standard drivers (not dedicated to just the controller), to be able to connect the headphones... you know, I didn't want the wife to be mad at me for being playing games at night....

I forgot to ask... how is going to be the process to pair the controller with the host receiver? I don't remember exactly, but in the old days of ScpToolkit and Motioninjoy there was a small utility to set the host's bluetooth mac to which the controller should connect when the user pressed the PS button... please correct me if I'm wrong... how is going to be now?

@pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

I forgot to ask... how is going to be the process to pair the controller with the host receiver? I don't remember exactly, but in the old days of ScpToolkit and Motioninjoy there was a small utility to set the host's bluetooth mac to which the controller should connect when the user pressed the PS button... please correct me if I'm wrong... how is going to be now?

That's still the same; you send a single request to the device via USB updating the host MAC address it shall connect to. This can be done via SCP, FireShock or even WinUSB and a bit of custom code. No biggie.

I'll provide a tool for that.

Ugh, I'm on a hunt. A bug hunt. And it's always issues I've introduced myself

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffe000c63b0dd4, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff800ccac6434, address which referenced memory

DRIVER_IRQL_NOT_LESS_OR_EQUAL is the most misleading bugcheck there is because the IRQL has little to do with this particular case, it's just me accessing freed memory:

A classic

Hello @nefarius,
What wonderful work you have been doing!

If you could put the code on github, (possibly just your “src” ans “include” directories {and licence of course}, so that noobs won’t compile and break their system.). It would allow some of us to have a more in-depth read-through of your code.

Otherwise, keep up the amazing work; I look forward to seeing the code in person.

Cam.

@da2ce7 Greetings. The plan is indeed to move to GitHub once the project is mature and stable enough. Right now it will stay private

Pop the champagne, another milestone reached

SIXAXIS/DualShock 3 and Navigation controller playable through Shibari

Youtube Video

After all this time of tinkering and watching byte streams I wanted to experience some results so I've modded Shibari to support the exposed children of the BthPS3 bus and look at them go

Now I can enter some serious testing and do benchmarks without having to write the function driver. In this example the bus children are in Raw PDO mode meaning that the PNP-Manager will bring them up without a function driver required and exposes them to user-land applications which then can talk to them via classic Win32-API CreateFile and DeviceIoControl.

This is of course only an "intermediate stage", I'll still provide HID-minifilter drivers so no additional software will be required to expose the controllers via HID/DI and (probably) XInput.

Stay tuned!

Castlevania Chronicles Pro-Gameplay by Gordon Freeman

Youtube Video

Pardon the shit quality, recorded this on my HTPC for authenticity and the i3 wasn't really happy

@nefarius Looking good there! Almost like it's ready for beta testers? It's been over a week without updates on my favorite tech blog!

@Locksmith said in Bluetooth Filter Driver for DS3-compatibility - research notes:

@nefarius Looking good there! Almost like it's ready for beta testers? It's been over a week without updates on my favorite tech blog!

Hey,

no worries, I'm still here, had to take a bit of a break, need to wipe my development PC and reinstall all the fun. Plus I've quit my day job and had to organize a few things and regain a proper sleep schedule

There'll be more updates soon.

Cheers

Hi Nefarious, i'm actually using your scp toolkit driver for windows, even if incomplete it works well, i have both a ds3 and a ds4, and i really hope that when this project will be finished, both pads will be supported! Congratulations for all the latest progress you made! ^^

@Luke76bg I hope for the same, mate glad it brings you joy, we're getting very close, just stay with me

@nefarius I'm not going anywhere! I can't wait! ^___^

Thank you very much for the effort you're putting into this project. I can't wait for the beta to be released and being able to use both bluetooth audio and my trusty Vault 13 canteen DS3 controller. Should you need testers, please count me in.

@nefarius any news?

Dear me, it's been a month! Time to see if the sources still compile

Alright, until the next demo is ready I shall at least write down a little To-Do kind of list of open topics

Profile driver

Auto-disconnect on buffer overrun threshold

I've seen that the Bluetooth sub-system keeps all input reports buffered if they're not "consumed" by the profile or function driver which could lead to non-pageable memory exhaustion in case of a bug where the function driver stops consuming and inherently emptying the buffer. I plan on realizing that with a buffer size threshold value of a few kilobytes which, when exceeded, will drop the connection of the controller as there is no "stop sending input reports" command to my knowledge. This protection mechanism should be part of the profile/bus driver as it is the last bastion to system stability

Same for the control endpoint if the "OK bytes" are forgotten to be consumed. Running out of precious non-pageable memory has to be avoided at all costs

Harden (dis-)connect state machine

The state machine is almost a 100% finished, I didn't cover a few edge-cases I can't test because I would need to introduce radio connection errors which I can't without the proper equipment, although should implement fallback paths so the driver won't end up in an unknown state and cause hangs or orphaned objects. Again, no open paths allowed in kernel land. They will bite back one day

Filter driver

This little fella basically works well but needs attention.

Add sideband channel

A filter can't be directly accessed to e.g. send it configuration changes. Therefore a sideband channel or control device object has to be introduced. This is a very good template to base it upon. The control object will be protected by ACLs only allowing administrative users access to protect against abuse. SDDL_DEVOBJ_SYS_ALL_ADM_ALL sounds right for this purpose (context).

Add support for multiple radios

The current assumption is that there's only one radio to work with. In a real world scenario this may be false since multiple "filter-able" Bluetooth host radio devices may be present. Therefore the filter should - in conjunction with the sideband mechanism - keep a reference to every device it's attached to and provide some sort of identification (bus serial, name, etc.). This will also impact the way the filter can be configured.

User-land configuration

It should be convenient for the end-user to enable or disable the drivers patching capabilities during runtime without the need of unloading the filter or having to re-plug or re-enable any devices. Some simple IOCTLs should be introduced for the sideband channel which can then be sent by a simple GUI tool. The driver should then store the state change in the according registry sections it can access (Hardware key sounds like the right place).

User-land tool for control

I plan on providing a simple C#-based tool which displays the available filtered radios with some basic information and some toggle switches to enable or disable PSM patching on the fly and other possible useful information which might come up (host radio MAC address for easy pairing access for example or entirely integrate PS3 pairing).

Setup tools

The recent discoveries of the ViGEm.Setup toolset may certainly benefit this project as well. Maybe portions of BthPS3Util should/could be ported to WiX custom action

Shibari/Function driver

Not entirely sure if I should continue/publish my Shibari hack which already makes this stack usable. Proper function drivers should be the end goal but those will once again eat quite a bit of time as well. We'll see about that.

So far so good, will ramp up the pace again soon.

Cheers

About to test the latest filter modifications (added sideband code), here we go again

Bless you, VMware

That's quite quick, RAM-cached hard disk provides quite the I/O

And we have a Desktop, that install only took 5 minutes

Oh, this if funny, I thought I've checked this already but apparently not; it's not possible to have two (or more) USB Bluetooth host dongles active at the same time

Windows 8.1

Windows 10

Well, that's good to know but hasn't interfered with anything I've implemented today because I wanted to have the capability of storing device-specific settings through a control device anyway. So I guess this is true

Phew, everything still works after my mayhem And on a completely fresh machine as well!

Time for a game and/or slumber

Alright, breakfast is done, back to work Looks like disabling the patching is working as expected:

2019/05/18-11:29:22.504	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
2019/05/18-11:29:22.504	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-11:29:22.504	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-11:29:22.504	TRACE_LEVEL_VERBOSE	>> Bulk IN transfer (PipeHandle: FFFFE000E7133D20)
2019/05/18-11:29:22.504	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Exit
2019/05/18-11:29:23.355	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Entry
2019/05/18-11:29:23.355	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-11:29:23.355	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-11:29:23.356	TRACE_LEVEL_VERBOSE	>> Bulk IN transfer (PipeHandle: FFFFE000E7133D20)
2019/05/18-11:29:23.356	TRACE_LEVEL_VERBOSE	UrbFunctionBulkInTransferCompleted Exit

Now onto making it dynamically changeable and storing it in the registry to make it survive device power cycling.

Wait a minute... After the first few denied connection requests when the controller shuts off and I retry to connect it there are no more requests flowing through the filter

Is this due to VMware? I don't think so... Hm, that sure is surprising me, I thought the host controller driver always has to be contacted in case of a new connection request but apparently it's cached in the actual chip somehow. Well, there goes my fabulous plan of making it dynamically configurable

I'll do a bit more testing and if I can't get it to work I'll simply rip out the control device again (was a good practice anyway) and introduce two Parameters registry values to globally control the patching. Taking a few steps back and not over-complicating things. There's other stuff in the pipeline

Hm, somehow VMware is not happy at all with what I'm doing, I'll now switch over to a physical machine and see how it's going there.

Aha! Deception! It actually was VMware! On a physical Windows 10 machine it works flawlessly like expected even with a 5 meter USB repeater:

Test with Nav Controller

---------------------------         Pressed PS button         ---------------------------
2019/05/18-12:40:54.722	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:40:54.722	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:41:13.495	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:41:13.495	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:41:32.280	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:41:32.280	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:41:51.049	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:41:51.049	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
---------------------------         Pressed PS button         ---------------------------
2019/05/18-12:42:55.355	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:42:55.355	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:43:14.135	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:43:14.135	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:43:32.912	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:43:32.912	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:43:51.675	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:43:51.675	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM

Test with DS3 Controller

---------------------------         Pressed PS button         ---------------------------
2019/05/18-12:46:10.193	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:46:10.193	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:46:28.964	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:46:28.964	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:46:47.736	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:46:47.736	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:47:06.502	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:47:06.502	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
---------------------------         Pressed PS button         ---------------------------
2019/05/18-12:48:06.959	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:48:06.959	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:48:25.733	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:48:25.733	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:48:44.510	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:48:44.510	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:49:03.293	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:49:03.293	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
---------------------------         Pressed PS button         ---------------------------
2019/05/18-12:50:40.865	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:50:40.865	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:50:59.650	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:50:59.650	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:51:18.423	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:51:18.423	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-12:51:37.183	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-12:51:37.183	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM

As you can see the controller tries for a total of 4 times to connect to the host its programmed to before giving up and shutting off. When I press the PS button again to wake it up within the same session the requests arrive again (and get blocked because patching is disabled in this example) as expected. Good stuff!

Now that I know I'm not entirely bonkers it's time to define some IOCTLs for the control channel. And some coffee

Good progress so far Time for a break and go for a little cycling tour while the weather is this nice

Oooopsie...

Mistake identified, copypasted a variable which in this case isn't initialized, argh!

Ha, there we go!

Let's go for a test:

2019/05/18-19:09:31.570	TRACE_LEVEL_INFORMATION	BthPS3PSM_SidebandIoDeviceControl Entry
2019/05/18-19:09:31.570	TRACE_LEVEL_VERBOSE	PSM patch disabled for device 0
2019/05/18-19:09:31.570	TRACE_LEVEL_INFORMATION	BthPS3PSM_SidebandIoDeviceControl Exit
2019/05/18-19:09:36.919	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-19:09:36.919	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-19:09:55.703	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-19:09:55.703	TRACE_LEVEL_VERBOSE	-- NOT Patching HID Control PSM
2019/05/18-19:09:57.801	TRACE_LEVEL_INFORMATION	BthPS3PSM_SidebandIoDeviceControl Entry
2019/05/18-19:09:57.801	TRACE_LEVEL_VERBOSE	PSM patch enabled for device 0
2019/05/18-19:09:57.801	TRACE_LEVEL_INFORMATION	BthPS3PSM_SidebandIoDeviceControl Exit
2019/05/18-19:10:14.487	TRACE_LEVEL_VERBOSE	>> Connection request for HID Control PSM 0x0011 arrived
2019/05/18-19:10:14.487	TRACE_LEVEL_INFORMATION	++ Patching HID Control PSM to 0x5053
2019/05/18-19:10:14.877	TRACE_LEVEL_VERBOSE	>> Connection request for HID Interrupt PSM 0x0013 arrived
2019/05/18-19:10:14.877	TRACE_LEVEL_INFORMATION	++ Patching HID Interrupt PSM to 0x5055

Splendid!

Storing and loading settings implemented, that will be all for today

One more command

Now off to important things

BthPS3 + Shibari Demo with Nav and DS3 Controller [19.05.2019]

It's time for another video I wanted to see if everything still works after the latest rework and so far everything's looking fine, also performance is stellar, even through Shibari which has to go from kernel to user to kernel context many times per second I notice no input lag whatsoever.

Youtube Video

Next I'll implement the buffer overrun protection.

@nefarius It looks great! I'm looking forward to testing this myself, keep up the good work!

@enricorov I still need a strategy on how to involve testers without unfinished binaries spreading...

@nefarius I suppose that's something hand in hand with invoving other people. You could have the software work only until a certain date, say a month from the beginning of beta, which would prevent people from using the beta binaries indefinitely.

@enricorov hm, a time bomb you mean? Well, I'll figure something out, another issue that's more important to me and would need assistance with would be how to properly organize such a circle of testers, having feedback arriving in a nice ordered fashion etc.

Auto-disconnect on I/O idle implemented

Alright, this challenge was easier to resolve than I initially thought (and without a single crash I might add!) thanks to the frameworks idle power-down capabilities:

--------------------------- Nav connecting ---------------------------
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Entry
2019/05/19-17:48:09.682	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 00070401E341 arrived
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Entry
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Exit (STATUS_NOT_FOUND (0xC0000225))
2019/05/19-17:48:09.682	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D), dropping connection
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Entry
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Exit
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Exit
2019/05/19-17:48:09.682	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Exit
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Entry
2019/05/19-17:48:10.488	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 00070401E341 arrived
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	IRQL DPC (0x02) too high, preparing async call
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Exit
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnectAsync Entry
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Entry
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Exit (STATUS_NOT_FOUND (0xC0000225))
2019/05/19-17:48:10.488	TRACE_LEVEL_INFORMATION	++ Device 00070401E341 name: Navigation Controller
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:10.488	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnectAsync Exit
2019/05/19-17:48:10.703	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Entry
2019/05/19-17:48:10.703	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/05/19-17:48:10.703	TRACE_LEVEL_INFORMATION	HID Control Channel connection established
2019/05/19-17:48:10.703	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Exit
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Entry
2019/05/19-17:48:10.897	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from 00070401E341 arrived
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	IRQL DPC (0x02) too high, preparing async call
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	BthPS3_IndicationCallback Exit
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnectAsync Entry
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Entry
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	ClientConnections_RetrieveByBthAddr Exit (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:10.897	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnectAsync Exit
2019/05/19-17:48:10.969	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x4, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:10.969	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
2019/05/19-17:48:10.969	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:11.092	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Entry
2019/05/19-17:48:11.092	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
2019/05/19-17:48:11.092	TRACE_LEVEL_INFORMATION	HID Interrupt Channel connection established
2019/05/19-17:48:11.092	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Entry
2019/05/19-17:48:11.092	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Exit
2019/05/19-17:48:11.092	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Exit
2019/05/19-17:48:11.092	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Entry
2019/05/19-17:48:11.093	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Exit
--------------------------- Device connected, but no I/O, 10 seconds idle timeout ---------------------------
2019/05/19-17:48:21.094	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfDeviceD0Exit Entry
2019/05/19-17:48:21.094	TRACE_LEVEL_INFORMATION	Requesting device disconnect
2019/05/19-17:48:21.094	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfDeviceD0Exit Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFF858FEFFB1B20]
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ HID Control Channel 0xFFFF858FEFFB1B20 disconnected
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFF858FEEE2CB20]
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ HID Interrupt Channel 0xFFFF858FEEE2CB20 disconnected
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ Both channels are gone, awaiting clean-up
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	ClientConnections_RemoveAndDestroy Entry (ClientConnection: 0xFFFF858FE830A0D0)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	ClientConnections_RemoveAndDestroy Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFF858FE830A0D0)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:48:21.237	TRACE_LEVEL_INFORMATION	EvtClientConnectionsDestroyConnection Entry (DISPOSING CONNECTION MEMORY)
2019/05/19-17:48:21.237	TRACE_LEVEL_VERBOSE	EvtClientConnectionsDestroyConnection Exit
2019/05/19-17:48:21.238	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtDeviceContextCleanup Entry
2019/05/19-17:48:21.238	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtDeviceContextCleanup Exit
--------------------------- Device connection dropped by profile driver ---------------------------

Now when something happens to the I/O dispatching (like a process crash or a bug in the function driver), the idle timeout will kick in preventing the buffers from filling up uncontrolled and dropping the connection:

--------------------------- Shibari active, dispatching I/O ---------------------------
2019/05/19-17:54:15.514	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Entry
2019/05/19-17:54:15.514	TRACE_LEVEL_VERBOSE	>> IOCTL_BTHPS3_HID_INTERRUPT_READ
2019/05/19-17:54:15.514	TRACE_LEVEL_VERBOSE	bufferLength: 50
2019/05/19-17:54:15.514	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Exit (status: STATUS_PENDING (0x00000103))
2019/05/19-17:54:15.544	TRACE_LEVEL_VERBOSE	Interrupt read transfer request completed with status STATUS_SUCCESS (0x00000000) (remaining: 0)
2019/05/19-17:54:15.544	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Entry
2019/05/19-17:54:15.544	TRACE_LEVEL_VERBOSE	>> IOCTL_BTHPS3_HID_INTERRUPT_READ
2019/05/19-17:54:15.544	TRACE_LEVEL_VERBOSE	bufferLength: 50
2019/05/19-17:54:15.544	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Exit (status: STATUS_PENDING (0x00000103))
2019/05/19-17:54:15.546	TRACE_LEVEL_VERBOSE	Interrupt read transfer request completed with status STATUS_SUCCESS (0x00000000) (remaining: 0)
2019/05/19-17:54:15.547	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Entry
2019/05/19-17:54:15.547	TRACE_LEVEL_VERBOSE	>> IOCTL_BTHPS3_HID_INTERRUPT_READ
2019/05/19-17:54:15.547	TRACE_LEVEL_VERBOSE	bufferLength: 50
2019/05/19-17:54:15.547	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoDeviceControl Exit (status: STATUS_PENDING (0x00000103))
--------------------------- Shibari killed by Task Manager so device is orphaned now ---------------------------
2019/05/19-17:54:15.558	TRACE_LEVEL_VERBOSE	Control read transfer request completed with status STATUS_CANCELLED (0xC0000120)
2019/05/19-17:54:15.558	TRACE_LEVEL_VERBOSE	Control read transfer request completed with status STATUS_CANCELLED (0xC0000120)
2019/05/19-17:54:15.558	TRACE_LEVEL_VERBOSE	Interrupt read transfer request completed with status STATUS_CANCELLED (0xC0000120) (remaining: 0)
2019/05/19-17:54:15.558	TRACE_LEVEL_VERBOSE	Interrupt read transfer request completed with status STATUS_CANCELLED (0xC0000120) (remaining: 0)
--------------------------- Idle timeout kicked in, dropping device ---------------------------
2019/05/19-17:54:25.558	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfDeviceD0Exit Entry
2019/05/19-17:54:25.558	TRACE_LEVEL_INFORMATION	Requesting device disconnect
2019/05/19-17:54:25.559	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfDeviceD0Exit Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFF858FE8E610D0)
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFF858FEEA47B20]
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ HID Control Channel 0xFFFF858FEEA47B20 disconnected
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFF858FE8E610D0)
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x3, Context: 0xFFFF858FE8E610D0)
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ IndicationRemoteDisconnect [0xFFFF858FF3EDCB20]
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ HID Interrupt Channel 0xFFFF858FF3EDCB20 disconnected
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Entry (STATUS_SUCCESS (0x00000000))
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ChannelDisconnectCompleted Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ Both channels are gone, awaiting clean-up
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	ClientConnections_RemoveAndDestroy Entry (ClientConnection: 0xFFFF858FE8E610D0)
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	ClientConnections_RemoveAndDestroy Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_INFORMATION	EvtClientConnectionsDestroyConnection Entry (DISPOSING CONNECTION MEMORY)
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	EvtClientConnectionsDestroyConnection Exit
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtDeviceContextCleanup Entry
2019/05/19-17:54:25.648	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtDeviceContextCleanup Exit
2019/05/19-17:54:25.649	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x1, Context: 0xFFFF858FE8E610D0)
2019/05/19-17:54:25.649	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
--------------------------- Device connection dropped, all memory freed ---------------------------

Nice, the list is getting shorter

@nefarius I am really glad to see progress and maybe soon a future where I will not have to use SCPToolkit in Windows 10 with my PS3 controller. I still prefer PS3 controller over the PS4 controller.

I have VMWare setup also with Windows 7 and 10 as well and if you need a beta tester I am more then willing. I use to do some software development for Database applications like Invoicing, Inventory, and Time software in Borland Delphi so I do know a bit about what to look for in bugs and how to report them.

Wow, that's an intense weekend @nefarius! I guess you'll have to swear the beta testers to secrecy with some blood oath and haunt them through the night if they do not report in! Great work, and it's really fun and interesting to follow the progress you post. Keep it up!

@molitar @Locksmith have a glimpse on the main page, should be a new category visible

@nefarius Ok great I am doing an image backup of my system right now and will be removing SCP and testing within the hour

Note to self: add WdfDeviceInitSetExclusive to PDO to prevent multiple handles.

Ok, finally had do register just to say I too have been following this story for months, and I don't know why (I'm not a programmer, unless you count some rudimentary VBA for Excel...), but coming to check in every few days is better than anything I find on Netflix; what an adventure! I do want to try this out once it is ready (I can only see source code on the main page, I still cant test it yet, right?), and will say goodbye to SCP then!

@RDP be my guest, I've updated your permissions.

finally,the long awaited progress is here
i hale thy for doing what everybody couldn't
but seriously i am a follower since day one
i think no one can deny the progress made in this month
i hope i am not asking for much but if it's possible i wish i too can be a part of making a legendary milestone

@seiif you've been added to the flock. Enjoy the ride.

pali, reporting for duty with only a hint of snark

Good luck with the testing! I've been following this for a while and can't wait to finally have a true replacement for SCP. I'm very excited with the progress you've posted. Thank you so much for your work on this.

The testing so far has been overwhelmingly good apart from some legacy SCP shenanigans ruining our fun with Shibari but that's a different topic and solvable.

Hi nefarius,

I too have been reading your posts on a regular basis and have been getting much enjoyment out of them (even if some of it is so technical it may as well be Chinese to me ).
While I'm not a hardcore coder, I love tinkering and would love to help out with testing. My machine is win 10 x64, soon to be 1903, with a Intel 9260 Bluetooth card, which hast had SCP installed on it. Currently have a Xbox 1 and ds4 controller paired to it and have two real ds3's to test with. Oh, and I also have a couple of no name bt adapters that I used to use with SCP that I could also use.

I wouldn't mind testing either if you're still looking for more people to help. I have access to two different Bluetooth adapters (this and this), an original DS4 controller, 2x original DS3 controllers, and 2x Xbox One controllers, as well as multiple computers I could use for testing (all Windows 10 1809 currently).

I do desktop and server support for a living, so I'm comfortable modifying the registry and adding/removing drivers and all that. Not sure what all might be needed in this scenario, but I'll do whatever you may need. Just let me know.

@teeedubb @chaoticyeshua welcome to the flock then, I've adapted your permissions, have fun

I'd like to test as well, here's my setup: original Sixaxis and DS3 with a Chinese clone. Bluetooth V4.0+EDR adapter (CSR8510). Had no success with AirBender. photo

If you are looking for any more beta testers please include me. I have 2 chinese DS3 controllers. and 2 bluetooth usb dongles (both bluetooth 4.0) and one bluetooth card built in to the laptop (bluetooth 4.2). I would love to help in anyway I can.

@ekze @Kue welcome aboard!

Hello, i have interest in beta testing too. I currently have two original DS3s that i use for playing with FireShock 1.3.1.0 via USB. Aditionally, i have a Bluetooth CSR2.1 USB adapter (VID_0A12&PID_0001). I've been reading this thread for a while and it's amazing the work you have been doing.

Hi! I am also interested in beta testing. I have a two real DS3s. This work is super exciting, I would love to hop on board!

Since test feedback has been very pleasing so far I'll cut back on recruitment today and implement the missing bits and pieces in the drivers and then throw them into the WHQL test bench. Will keep you updated.

Jo, it's WHQL-o-clock

This time the filter is my primary test subject. Fingers crossed!

Oh yes, give me more green! All the green tick marks!

@tulio150 @ryantburke done, welcome!

@Poosaurus you too

Dammit, almost...

What's going on here....

STACK_TEXT:  
nt!DbgBreakPoint
Wdf01000!imp_WdfCollectionRemove+0x2d1 [d:\win8_ldr\minkernel\wdf\framework\kmdf\src\support\fxcollectionapi.cpp @ 270] 
wdftester!wdftester_WdfCollectionRemove+0xfe
BthPS3PSM!BthPS3PSM_EvtDeviceContextCleanup+0x103 [d:\development\git.vigem.org\bthps3\bthps3psm\device.c @ 372] 
Wdf01000!FxObject::DisposeChildrenWorker+0x2fa [d:\win8_ldr\minkernel\wdf\framework\shared\object\fxobjectstatemachine.cpp @ 1188] 
Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc [d:\win8_ldr\minkernel\wdf\framework\shared\object\fxobjectstatemachine.cpp @ 814] 
Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xfb [d:\win8_ldr\minkernel\wdf\framework\shared\object\fxobjectstatemachine.cpp @ 894] 
Wdf01000!FxObject::EarlyDispose+0x117 [d:\win8_ldr\minkernel\wdf\framework\shared\object\fxobjectstatemachine.cpp @ 460] 
Wdf01000!FxPkgPnp::PnpEventRemovedCommonCode+0x1e2 [d:\win8_ldr\minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 2047] 
Wdf01000!FxPkgFdo::PnpEventFdoRemovedOverload+0x9 [d:\win8_ldr\minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgfdo.cpp @ 1244] 
Wdf01000!FxPkgPnp::PnpEnterNewState+0x1a1 [d:\win8_ldr\minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1231] 
Wdf01000!FxPkgPnp::PnpProcessEventInner+0x122 [d:\win8_ldr\minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1147] 
Wdf01000!FxPkgPnp::PnpProcessEvent+0x18d [d:\win8_ldr\minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 933] 
Wdf01000!FxDevice::DeleteDeviceFromFailedCreateNoDelete+0x13e [d:\win8_ldr\minkernel\wdf\framework\kmdf\src\core\fxdevice.cpp @ 530] 
Wdf01000!FxDriver::AddDevice+0x158 [d:\win8_ldr\minkernel\wdf\framework\kmdf\src\core\fxdriver.cpp @ 550] 
nt!PpvUtilCallAddDevice+0x45
nt!PnpCallAddDevice+0xd5
nt!PipCallDriverAddDevice+0x661
nt!PipProcessDevNodeTree+0x2b2
nt!PiRestartDevice+0xc7
nt!PnpDeviceActionWorker+0x313
nt!ExpWorkerThread+0x111
nt!PspSystemThreadStartup+0x194
nt!KiStartSystemThread+0x16

Alright, what went wrong there on device disposal...

--- start of log ---
1: FxIFRStart - FxIFR logging started
2: LockVerifierSection - Increment Lock counter (2) for Verifier Paged Memory from  \REGISTRY\MACHINE\SYSTEM\ControlSet001\services\BthPS3PSM from driver globals FFFFFA8009A2B970
3: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
4: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FF58B94E8 !devobj 0xFFFFFA800AD37C20 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
6: FxDevice::DeleteDeviceFromFailedCreateNoDelete - WDFDEVICE 0000057FF58B94E8 !devobj FFFFFA800AD37C20 created, but EvtDriverDeviceAdd returned status 0xc0000001(STATUS_UNSUCCESSFUL) or failure in creation
7: FxDevice::DeleteDeviceFromFailedCreateNoDelete - WDFDEVICE 0000057FF58B94E8, !devobj FFFFFA800AD37C20 is a filter, converting 0xc0000001(STATUS_UNSUCCESSFUL) to STATUS_SUCCESS
8: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FF58B94E8 !devobj 0xFFFFFA800AD37C20 entering PnP State WdfDevStatePnpRemoved from WdfDevStatePnpInit
9: FxChildList::NotifyDeviceRemove - WDFCHILDLIST 0000057FF597F388:  removing children
10: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FF58B94E8 !devobj 0xFFFFFA800AD37C20 entering PnP State WdfDevStatePnpRemovedChildrenRemoved from WdfDevStatePnpRemoved
11: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000057FF58B94E8 !devobj 0xFFFFFA800AD37C20 entering PnP State WdfDevStatePnpFdoRemoved from WdfDevStatePnpRemovedChildrenRemoved
12: FxPkgIo::StopProcessingForPower - Perform FxIoStopProcessingForPowerPurgeNonManaged for all queues of WDFDEVICE 0x0000057FF58B94E8
13: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 0000057FF59F0368, Waiting on Dispose event FFFFF880031B0AD0
14: imp_WdfCollectionRemove - WDFOBJECT 0000057FF58B94E8 not in WDFCOLLECTION 0000057FF57BAF78, 0xc0000225(STATUS_NOT_FOUND)
---- end of log ----

Oh How did I manage to provoke that. Well, back to fixing stuff

Very impressive work, would be interested in beta testing with an original Sixaxis DS3 and Bluetooth 4.0 adapter.

In my previous test run the filter crashed at the test Wdf - Kmdf Fault Injection Test

This test is actually amazing! Summary:

For each DDI that has been configured for fault injection, the WdfFiTester tool returns an NTSTATUS code of STATUS_UNSUCCESSFUL. The driver is expected to handle the failure.

That is really cool! It means, that it uncovers continued code execution where a faulty return code of a WDF function call isn't caught properly, which may lead to a crash (as demonstrated in my last run). I think I've nailed down the issue in my code and just started another run. Fingers crossed

Beyond impressed with this. I've been wanting to use the PS3 Navi remote for my HTPC for years, but I didn't have the willpower to dig into it like you have. Also, thanks so much for the PS4 remote drivers. They worked flawlessly. Now able to use the Nvidia shield without having to pair/unpair its remote (next step is to run Steam Link on the Pi and then use it directly on that in a different room).

Also happy to beta test, although it looks like you have plenty - I have a plethora of Windows machines, Pi's and Android TVs and tablets (also, as an aside, I'm also happy to give advice on career paths into coding if it will help - I manage teams of coders, previously at Atlassian, now about to join a startup. Was surprised to read it's been difficult).

Looking forward to the final commit!

Man i've been reading your notes for a while now, it has been one interesting adventure even when i know very little about software coding. i'll be looking forward to send you a tip or buying the final version once its done! (idk if im mistaken or not but i remember you have a patreon going by nefarious soft solutions... right?).

On a side note im using a genuine Sixaxis DS3 so i don't know if thats useful for beta testing (considering how many already got enroled) also im using a Wifi-Bth combo card (Qualcomm atheros) with scp.
Cheers!

Why WHQL though...

Why am I wasting so much time and resources on WHQL testing? Well, quick real-life demonstration on why cross-signing (misleadingly referred to as self-signing) kernel-mode code with an EV certificate alone in Windows 10 (UEFI, SecureBoot) doesn't work

Installation attempt of filter driver

Environment details

INF (CAT) signed and happily offered

So far so good...

Uh oh, restart required, not promising...

And there we have it

Now with "Secure"Boot off

SecureBoot directly influences Code Integrity settings applying to the kernel with a rather drastic impact:

So this would be production-ready. Except the cross-signed binary will not load when the rather common SecureBoot is enabled in UEFI. The Server Edition should be even more restrictive and not load cross-signed drivers anymore even without SecureBoot starting from Server 2016 IIRC. Yay...

@keefey hi! Well, currently it appears to be working fine, the whole self-employed coder thingy just need to clone myself hehe. Yeah my "mainstream" coding career never took off so here I am being my own boss

@ChileanHugDealer heya! Thanks for the encouragement, I do have a Patreon and currently got enough testers and so far I'm pleased with the overall results and now need to focus on getting this stack production-ready.

Cheers

Status update

We're almost feature-complete on both profile/bus and filter driver.

A very good suggestion I still have to fully implement. The downside of the filter being active is interference with other common devices like the DS4 in "PC mode" and apparently also some branches of Xbox One compatible controllers? I currently only own an Xbox One Elite pad and that requires its own 5 GHz wireless adapter which isn't Bluetooth anyway

So since the filter sits too low (USB/URB level) to know anything about the HCI/L2CAP state machine, it relies on some outside factors to decide if it should patch or not. So we thought about this flow:

• Filter is active, PS3 peripherals can connect to profile driver
• DS4 in "PC mode" connects, gets redirected to profile driver because PSM got patched
• Profile driver denies connection with CONNECT_RSP_RESULT_PSM_NEG and instructs filter to disable itself for like 10 seconds
• User presses PS button on DS4 to retry connection
• Connection now successful due to filter being temporarily disabled
• Timer enables filter again on its own to minimize required user interaction

I haven't found a way to reject a connection attempt without the DS4 giving up so the only remaining inconvenience would be the user having to connect the controller twice if the filter is active. Other than that I think we thought off every possibility to minimize the negative impact on user experience.

What do you think?

@nefarius i think that you are breathtaking.

Anyway it's a good solution if there aren't other methods.

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

• Profile driver denies connection with CONNECT_RSP_RESULT_PSM_NEG and instructs filter to disable itself for like 10 seconds
• User presses PS button on DS4 to retry connection
• Connection now successful due to filter being temporarily disabled
• Timer enables filter again on its own to minimize required user interaction

I haven't found a way to reject a connection attempt without the DS4 giving up so the only remaining inconvenience would be the user having to connect the controller twice if the filter is active. Other than that I think we thought off every possibility to minimize the negative impact on user experience.

What do you think?

Great job! Thank you for the efforts you put in this along with the team.

I'm not so into technical stuff, but I'll try my best here.

The whole "reconnect" concept reminds of InputMapper 1.6. On the other hand, DS4Windows 1.7.5+ reestablishes the connection without the user initiating it manually. Just a reminder, both of these programs use ViGEm drivers.

How does one (DS4W) achieves it while the other doesn't?

@AnyHoLiC said in Bluetooth Filter Driver for DS3-compatibility - research notes:

How does one (DS4W) achieves it while the other doesn't?

They don't. They don't/can't interfere with the Bluetooth connection process as that's completely abstracted away from them. They can send regular disconnect requests which works fine as long as the connection sequence isn't manipulated and the DS4 remains in "PC mode". The DS4 is a bit of a bastard child in this regards; even when once successfully paired to a Windows machine, once it has been turned off and turned on again it sneakily tries to connect in "PS4 mode" (a.k.a. directly establish HID Control and HID Interrupt L2CAP channels) which usually gets immediately rejected by the Windows Bluetooth stack and it tries again in "PC mode". Now with my filter patch active, the connection is - unexpectedly - routed through and the side effect I described happens. So this listing is my proposed solution/workaround until a better solution surfaces.

Cheers

@nefarius Thanks for the explanation.

So far the only issues I have while connecting DS4 to Windows (Windows 10, specifically) are the most common ones, while using IM and DS4W, which are:

1. It takes longer to establish a connection compared to connecting to a PS4.
2. Latency.
3. Using it with Uplay (Ubisoft's) is basically unusable, which continuously switches back and forth between X360 and DS4 modes.

I have yet to install ViGEm directly using PowerShell without using any extra programs.

You don't have to reply to this.

Thanks again for your insight.

@AnyHoLiC said in Bluetooth Filter Driver for DS3-compatibility - research notes:

I have yet to install ViGEm directly using PowerShell without using any extra programs.

PowerShell ain't no more mate see the news

@nefarius Funny, i have to connect my ds4 to scptoolkit twice too, to get it recognized! I can't wait to try it, i need autofire for bloodstained and joytokey auto repeat doesn't work...However twice or not, your work is amazing!!!

Survey: Desired Windows OS compatibility

Ladies and gents, it's getting serious! I need community feedback on where to go from here with the singing fun for the production release. I've crafted a poll with the first answer being the most convenient and fast but most exclusive route and the last one being the most annoying but also most inclusive. Hop on, your voice matters!

BthPS3 - Desired Windows OS compatibility

Cheers

Quick intermediate survey result summary after being up slightly over a week:

Well, lots of Windows 10 fans it seems

By the way, another advantage of going with the "ditch legacy OS support completely" option will be: I can develop the function driver (HID-miniport driver, for DI/Unity/PCSX2/... compatibility, pressure exposure etc.) with the User-Mode Driver Framework which would have loads of advantages (dev speed, debugging, stability, quick release cycles, ...) so that would be another step up in motivation for me.

More news to come!

Speaking of which, I was curious about how much information the filter driver would support for the DualShock 3. I was thinking that because it has basically "native" support when patched, everything would work, but do you have to program functions in so that pressure sensitivity and other DS3 related controller functions passed that information along to Windows?

@anontsuki that's the job of the function driver which still has to be written, but that's "easy" compared to what was achieved 'till now. So in the ultimate end result Shibari as a proxy application won't be necessary anymore at all.

Very cool. I look forward to the entire thing being complete, whenever that time comes =).

When the first release is scheduled ?

@Luke76bg am still unsure if I should do a "requires Shibari" release or go all in. The latter would definitely take even more time and I gotta balance it with my current workload. Other than that, maybe September?

@nefarius Shibari was crashing when disconnecting a controller by bluetooth or when an connected controller by bluetooth was connected then by USB, I remember it spawned 2 controllers in this situation or something like that.
Unless these issues can be really easily fixed in a day or two, I'd vote for you to focus on the release with no companion app, even if it takes longer.
Good luck, Nefarius, and have a nice day!

@kirian everything that's a pure Shibari issue can be fixed with ease. I just don't put much effort into hardening it because of time budget. Drivers need to be rock solid, that's number one.

@nefarius Thanks for the answer Nefarious, i'm sure it will be an amazing piece of software! I can't wait! ^^

@nefarius i can't wait too.

For the release schedule you said "early may" u.u (i'm here following your news since march X'D)

But i'd always think that it's better to wait more for a better "product", thanks for your work :).

@epikvigem there's a few topics who threw off the schedule:

• Windows 10 1903 changes apparently breaking kernel drivers left and right. Did quite a bit of research on that to break through all the misinformation on the web.
• WHQL lab advances. This took the most time, setting up the lab and running a lot of tests. Tedious and costly.
• Working on paid commissions. Ever since I've started the business I'm also doing contracted work. That wins ofc. over this hobby-ish fun topic as this stuff doesn't pay the bills as long as the Patreon and other sources of income are low That's just how life is. More funds, more speed. Simple formula.

Cheers

since airbender doesnt work, it's safe to uninstall it right?

@kempol sure! Can be removed anytime!

Posted on PCSX2 forums

Related thread, for the record. Might or might not go somewhere. Time will tell.

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

Posted on PCSX2 forums

Related thread, for the record. Might or might not go somewhere. Time will tell.

What happened? I though that this project was going well....

@pnkiller78 Pardon, it appears like I should've been more specific in my wording. I meant let's see if the thread over there grabs some attention which it currently doesn't appear to do. Meanwhile I'll continue my shenanigans over here as usual

@nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

@pnkiller78 Pardon, it appears like I should've been more specific in my wording. I meant let's see if the thread over there grabs some attention which it currently doesn't appear to do. Meanwhile I'll continue my shenanigans over here as usual

Oh, I see, I was worried that something might have cause you to lost interest....
I'm waiting with great anticipation for this project to become official... I think it's pretty cool what you have done here.

Note to self: do a release soon before losing your mind

Dammit, I hate leaving empty functions behind to pick up later, what did I originally plan to do in here

I am still here. Have almost figured out literally everything, stay with me ️

Exiting keep up the good work

I can't wait!!!! O_O

Back in business, warming up with some documentation. Also moved to GitHub since in the meantime they allow free private repositories

Also upgraded to Visual Studio 2019 and WDK 10 1903, no biggie, but it's mature enough to use now in my taste

Documentation has become equally important, this project got huge fast!

Speaking of complexity; a bit of ASCII art I've come up with for this fun

Device tree

     +----------------------+                                +----------------------+
     |    Navigation PDO    +<----------+         +--------->+      Motion PDO      |
     +----------------------+           |         |          +----------------------+
                                        |         |
                                        |         |
                                        |         |
                                        |         |
                                        |         |
+----------------------+          +-----+---------+------+         +----------------------+
|      SIXAXIS PDO     +<---------+ Profile & Bus Driver +-------->+     Wireless PDO     |
+----------------------+          |     (BthPS3.sys)     |         +----------------------+
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  | Bluetooth Enumerator |
                                  |    (bthenum.sys)     |
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  |     bthport.sys      |
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  |      bthusb.sys      |
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  | BthPS3PSM.sys filter |
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  |       USB Stack      |
                                  +----------+-----------+
                                             ^
                                             |
                                             v
                                  +----------+-----------+
                                  | USB Bluetooth dongle |
                                  +----------------------+

On the Discord server I've added a push notification for this projects repository, in case you wanna stalk my progression even more

Build script for future CI/CD fixed as well: